Thoughts about in contract inheritance

Stewart Gordon smjg_1998 at
Wed Feb 29 08:26:49 PST 2012

On 29/02/2012 14:44, Timon Gehr wrote:
>> 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 or or as I look at the moment.

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

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

> Library writers shouldn't silently change functionality and/or redefine interfaces.

So you think that, once a library is written and released, no new functionality should 
ever be added?


More information about the Digitalmars-d mailing list