Broken contract programing

[Idan Arye via Digitalmars-d]

On Wednesday, 13 May 2015 at 21:45:30 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 13 May 2015 at 18:32:17 UTC, Idan Arye wrote:
>> On Wednesday, 13 May 2015 at 17:47:27 UTC, Ola Fosheim Grøstad 
>> wrote:
>>> On Wednesday, 13 May 2015 at 14:54:05 UTC, Benjamin Thaut 
>>> wrote:
>>>> On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
>>>>> This will accept the same arguments as Base. Only one 
>>>>> in-contract in the inheritance chain must pass in order for 
>>>>> the call to go through.
>>>>
>>>> But wasn't exactly that the problem about the current 
>>>> implementation? Shouldn't all 'in' contracts in the chain be 
>>>> checked?
>>>
>>> The topic is non-trivial. Dart has even deliberately picked 
>>> an unsound inheritance typing-model because it is more 
>>> useful. Consider the following scenario:
>>>
>>> You have a superclass Shelter, then you create subclass 
>>> DogShelter. The Shelter has a virtual function add_pet(Animal 
>>> x) . So clearly the DogShelter will have to accept the _type_ 
>>> Animal in its add_pet specialization because of the type 
>>> system.
>>>
>>> That does not mean it is not a bug if you bring a Cat to the 
>>> DogShelter. It merely means that you cannot catch such bugs 
>>> with the type system alone. The DogShelter might sit behind 
>>> another infrastructure that is supposed to prevent non-Dog 
>>> animals from entering.
>>>
>>> So it makes sense to not conflate invariants/contracts with 
>>> the type system.
>>
>> http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
>
> Yes… and your point is?

That a type system can solve this problem if it supports 
covariant and contravariant generic/template parameters.