DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Thursday, 22 June 2017 at 06:43:38 UTC, H. S. Teoh wrote:
> On Thu, Jun 22, 2017 at 05:46:06AM +0000, MysticZach via 
> Digitalmars-d wrote: [...]
>> As far as syntax subtrees not belonging to their parent, I can 
>> see where the cognitive dissonance comes from. But it just 
>> doesn't seem that bad to me, since contracts are always 
>> executed as if they are sequential statements anyway.
> [...]
>
> Then possibly you're missing the point behind DbC.  The idea of 
> "executing" a contract seems to indicate that you're taking the 
> current D implementation of it as normative.

I understand. Thus, a better DIP would suggest reimplementing D's 
DbC system altogether. Because as it is, they are little more 
than syntax dressing, which happens to be less convenient that 
just writing out the asserts in the first place. They're more 
like syntax _vinegar_ than sugar. Which explains why hardly 
anyone uses them. Why write this:

int fun(int a)
in { assert (a); }
do {
     return a;
}

...when you could just do this:

int fun(int a) {
    assert(a);
    return a;
}

With your improvement, it's a little better,

int fun(int a)
in (a)
{
     return a;
}

...but the cost is that `assert` is implied, and no other system 
of checking is allowed, which seems like a sufficient flaw to 
make it not decisively better. To solve this, you'd have to 
decouple `assert` from the contract, requiring this:

int fun(int a)
in (assert(a))
{
    return a;
}

This also looks good. But now the grammar is weird because it's 
just an expression in there without a statement, which doesn't 
happen anywhere else in D.

I start to get the nagging feeling that your point about the 
limitation in D's DbC implementation is actually the fatal flaw 
here. It's currently _illegal_ (outside of interface 
declarations) to expose the signature separately from the body, 
which, as you point out,  is more or less the whole point of DbC. 
<shrug> The existing system is itself distinctly _worse_ than 
just writing out asserts manually... and as far as I can tell,  
none of the alternative syntaxes is a decisive improvement over 
it. Yours looks the best, but implying `assert` in the grammar 
seems to be going too far, especially for a DbC system that is 
only half functional. If the `assert` system were made more 
user-definable, it would make more sense. Do you agree with me on 
this?

Plans to improve `assert` are already in the air. Maybe we should 
wait on them before promoting your suggestion?