On 05/13/2015 04:54 PM, 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?

No, this is done right. (What I meant to say was that one passing in-contract in the inheritance chain is sufficient.)

> Shouldn't all 'in' contracts in the chain be checked?

They are all checked in turn until one is successful.

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?

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.

On Wednesday, 13 May 2015 at 23:49:51 UTC, Idan Arye wrote:
> That a type system can solve this problem if it supports covariant and contravariant generic/template parameters.

Not if someone else provided the super class, and generics simply bypasses the OO-inheritance model. Anyway, the key point was that uses of type systems that are workable (not overly tedious) can only catch the most obvious bugs at compile time. Therefore it is useful to be able to constrain invariants to a point where they ensure correctness, not type-soundness.

Am Wed, 13 May 2015 14:35:53 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 05/13/2015 02:16 PM, Idan Arye wrote:
> >>
> >
> > I think the `in` contracts check should be statically dispatched, so that only the contracts relevant to the reference-type you are calling the method from will be checked.
> 
> https://issues.dlang.org/show_bug.cgi?id=6857

This discussion over there was quite a thriller. From the
first post it looked like a clear case to me: I pass an 'A'
into 'foo', so I deal with 'A's API which includes the
contracts it defines and what methods are declared. Seemed so
logical. Then Walter & Andrei were all like "Guys read up
on OOP, you seem not to understand the details! The way we
handle contracts is the only possible way!", passing the
argument by authority up to Meyer.
And finally Meyer himself had to think for a moment before
saying the static type should probably be checked for
contracts, not the dynamic one and his book wasn't explicit
about it either, but it could be deduced.

So much energy went into writing endless repetitive comments,
that could have been put into trying to understand the issue
at hand and revalidating ones views and memories when four or
more people hint at a blind spot.
Maybe one has to be in the situation where one constantly
has to put energy into proving to people who made up a new
feature in 5 minutes, why exactly it is not going to work.

Anyways the bug is pre-approved and looking for someone to hack on the compiler.

-- 
Marco

P.S.:
I just noticed I had a misconception about in-contracts, too.
Where I thought they would be inherited per method override,
it is actually the case that not copying the in-contract
states that my derived method will work with any input. So
this was all very educational at least.