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.
