Crash in out contract in interface

[Timon Gehr]

On 08/24/2011 07:57 PM, Andrei Alexandrescu wrote:
> On 8/24/11 9:45 AM, Timon Gehr wrote:
>> On 08/24/2011 04:47 PM, Andrei Alexandrescu wrote:
>>> On 8/24/11 6:58 AM, Timon Gehr wrote:
>>>> So, basically interfaces are the only place in D?/DMD where you can
>>>> even
>>>> specify contracts without a function body and there they don't work. I
>>>> think the bug is not the only problem, actual contracts should /always/
>>>> be part of the function declaration and not require an
>>>> implementation to
>>>> work. Everything else degrades contracts to simple syntactic sugar for
>>>> assertions.
>>>
>>> That plus interplay with inheritance.
>>>
>>> Andrei
>>
>> Well, yes, that is true. Where one can add contracts, they will be
>> inherited. But inheritance is actually where D's current contract
>> programming model is weakest:
>>
>> It should be possible to use inheritance to create classes that move
>> gradually from unimplemented, but specified to implemented and extended.
>> The fact that unimplemented methods in an abstract class cannot define
>> contracts is an unforgivable left-out, because that is where contracts
>> are most useful: for the specification of what all implementations of
>> the method are allowed to assume and must guarantee.
>
> Indeed. That should be filed as a bug. But you are exaggerating a bit
> because as you yourself note there are obvious workarounds.
>

Done: http://d.puremagic.com/issues/show_bug.cgi?id=6549

Note that none of the workarounds I could think of does not invade the 
inheritance interface. When I am talking about so-called 'issues' the D 
programming language has, I always mean 'issues from a highly purist and 
perfectionist standpoint'. If the goal is to have absolutely perfect 
contract programming support in D, then I think my statements are not 
exaggerated. But if it helps, I can choose my words more careful next time.

>> Contracts are declarative:
>> "If you guarantee this, I will guarantee that."
>>
>> Contracts and implementation are two completely orthogonal concepts,
>> and there is no reason to couple them in any way. Not allowing
>> contracts without implementation is like telling a customer "You are
>> not allowed to specify your needs unless we have already written code
>> to satisfy them."
>>
>> Do you agree that this will have to be fixed eventually, when all the
>> more important features are fully working?
>
> You should know that we introduced contracts in interfaces in spite of
> considerable implementation difficulties. So yes, we do consider
> implementation-less contracts important.
>

Great. I appreciate that. I blindly assume that implementation-less 
contracts in classes will be simpler to implement than contracts in 
interfaces.