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

[MysticZach via Digitalmars-d]

On Thursday, 22 June 2017 at 20:02:17 UTC, jmh530 wrote:
> On Thursday, 22 June 2017 at 18:57:40 UTC, MysticZach wrote:
>> [snip]
>
> I don't mind that so much, but you made a good point earlier on 
> how out would work with it.
>
> The whole double parentheses is a bit ugly to me. Is there any 
> problem with
> out(return > 0)
> instead of
> out(r) (r > 0)

The current grammar for `out` is:

OutStatement:
    out { Statement(s) }
    out ( Identifier ) { Statement(s) }

If the out contract with the new syntax had only one assertion, 
and that assertion were a single identifier, there would be a 
parsing ambiguity:

int fun(int a) {
    int nested(int b)
    out (b) // out with a single assert, or out with identifier 
and brackets?
    {
       assert(b); // function body, or `out` contract?
    }
    do { ... } // function body, or do-while loop?
    while (true); // only here do we finally figure it out
}

There's probably an easy way to tidy this up, but I couldn't 
think of one off hand, so I suggested `out ( ) ( IfCondition )` 
as an unambiguous alternative. It would in fact be the rare case, 
since most `out` contracts will just want to check the return 
value.

> Also, I can see the point of Critique 5 in the DIP for not 
> including in/out anywhere and wanting to pin it to the top of 
> the body. The suggestion in your post at least succeeds at that.

I assume you mean H.S. Teoh's suggestion? If it's as good as the 
others seem to think, hopefully it will succeed more than that... 
but preventing enhancement 5 is as simple as having the compiler 
issue an error if the user violates the rule that contracts must 
occur first and be grouped together in the body.