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.
