Broken contract programing

[Benjamin Thaut via Digitalmars-d]

On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
> On 05/13/2015 12:51 PM, iackhtak wrote:
>> There was discussion about broken contract programing. One 
>> broken
>> thing was "in" contract within inheritance. If you add 
>> different
>> "in"-contract in overridden parent and derived function only 
>> one
>> will be checked.
>
> No, this is incorrect. Only one needs to pass and if one does 
> not, the other is checked as well.
>

Wasn't the point that the set of values the derived contract 
accepts must be  a superset of the set of values the base 
contract accepts? E.g.

class Base
{
int foo(int x)
in { assert( x >= 0; );
body { ... }
}

This would be ok:

class DerivedOk : Base
{
override int foo(int x)
in { assert( x >= 0 || x < -5 ); }
body { ... }
}

This would be broken:

class DerivedBroken : Base
{
override int foo(int x)
in { assert( x >= 0 && x < 5 ); }
body { ... }
}

Because if you have a pointer to the base type it must always 
work with the contract specified in the definition of the base 
type (because that is most likely the only thing the client 
sees). So further restricting the possible range of values will 
possibly break code when swapping out implementations. However 
increasing the range of possible values will not break when 
swapping implementations.