Thoughts about in contract inheritance

[Stewart Gordon]

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.

<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.

<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?

<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?

Stewart.