Thoughts about in contract inheritance

[Timon Gehr]

On 02/29/2012 07:06 PM, Stewart Gordon wrote:
> On 29/02/2012 17:01, Timon Gehr wrote:
> <snip>
>> 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".
>
> But the comment "// <-- assumed to inherit contract" isn't actually
> there, so what's "quite explicit" about it?

That was just for documentation... The part that is explicit is:

// Single inheritance of state
class ExtendedWidget : Widget {
     override void print(uint level)
     in { /* weakening precondition is okay */ } body {
         ... level may be 0 here ...
     }
}

The fact that this weakens the precondition tells us that it was not 
weakened before.

> Besides, the interface
> declaration there isn't allowed by the grammar.
>

The compiler implements it.

> <snip>
>
>> 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.
>
> You mean the fault lies on the part of the library creator for widening
> the in contract of a non-final method?
>

Sure. This adds additional requirements that any deriving class needs to 
fulfill. It is not a backwards-compatible change.

> <snip>
>> Obviously there can be additional changes without redefining what an
>> existing part of the
>> API does.
> <snip>
>
> So you consider illegal inputs to a function to be part of the API?
>

Yes. Put differently, I consider legal inputs to a overridable virtual 
function to be part of the API.