Thoughts about in contract inheritance

[Timon Gehr]

On 02/29/2012 05:26 PM, Stewart Gordon wrote:
> On 29/02/2012 14:44, Timon Gehr wrote:
> <snip>
>>> The spec isn't explicit on whether the overridden method retains the
>>> base's in contract unchanged or loses its in contract altogether.
>>
>> The front page of the web site is quite explicit about this:
>
> What web site? Certainly not www.digitalmars.com or
> d-programming-language.org or dlang.org as I look at the moment.
>

The official website, d-programming-language.org or dlang.org. You have 
to click on "See example". It is at the first bulb of "Power".

> <snip>
>> Anyway, probably it is not stated explicitly in the relevant parts of
>> the spec because it
>> is assumed that the reader is familiar with similar features in other
>> languages.
>
> Then it's a hole in the spec. If it's only meant to state how D differs
> from some other language, it would have to state what language that is.
>

It surely is a hole in the spec.


> <snip>
>>> Another scenario I've thought of is:
>>> - library class defines a method with an in contract
>>> - application class overrides this method, and has the same argument
>>> restrictions as the library class
>>> - a later version of the library class widens the range of acceptable
>>> inputs
>>> - however, the app's override is not prepared to deal with inputs that
>>> are newly allowed by the API
>>>
>>> ...
>>
>> This is not a contract-related problem. It is a breaking API change,
>> whether or not the
>> library class defines language level contracts.
>
> How do you mean?
>

Language level contracts as in D are (basically) a way to introduce 
runtime checks into interfaces. If the interface is redefined then that 
potentially breaks all code that implements the interface, even if this 
is not explicitly stated in form of contracts.

> <snip>
>> Library writers shouldn't silently change functionality and/or
>> redefine interfaces.
> <snip>
>
> So you think that, once a library is written and released, no new
> functionality should ever be added?
>

Obviously there can be additional changes without redefining what an 
existing part of the API does.

Timon Gehr wrote:
> The new stuff should be introduced under a different name and the old name should be deprecated.