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

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 13:11:10 UTC, MysticZach wrote:
> [...]
>
> My fix would be to require two sets of parentheses for the new 
> conditional, like so:
>
> OutStatement:
>    ...
>    // new version
>    out ( Identifier ) ( IfCondition )
>    out ( ) ( IfCondition )
>
> This makes the grammar unambiguous and clean. And because 
> normally `out` contracts want to check the return value, the 
> last case, `out ( ) ( ... )` will be the rare one.

If I read that correctly as

---
int myFunc(Args...)(Args args)
   if (Args.length > 2)
   in (args[0] != 0)
   in (args[1] > 1)
   out (result)(result > 0) { ... }
---

then yeah, I would be happy with that, as well (and would love 
for the DIP to do this instead).


> If you do accidentally forget the extra set of parens on the 
> `out` contract, you would get "Error: `do` expected before 
> function body after a bracketed `out` contract" at the end of 
> the function.
>
> (If, however, it a happens to be a nested function, and the 
> next statement in that function happens to be `do`, then the 
> parser will think the `do` loop is the function body... Mmmm, 
> is this worth worrying about??)

Could you give a specific (short) example of what you think of?
I don't see any potential for ambiguity in the following at a 
quick glance, so I'm not sure I got where you think the problem 
lies:

---
void foo()
{
     int bar(Args...)(Args args)
       if (Args.length > 2)
       in (args[0] != 0)
       in (args[1] > 1)
       out (result)(result > 0) { ... }
     do {} while (true);
}
---