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

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:
> On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:
>> On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:
>>> On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
>>>> On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner
> Adding `if (...)` should not be different from adding `in 
> (...)` or `out (...)` in terms of syntax rules: it's 
> inconsistent. If you want to have that `do` there, I would 
> argue that it should also become required if only an `if (...)` 
> is present, so
>
> ---
>  int myFunc(Args...)(Args args)
>    if (Args.length > 2)
>    { ... }
> ---
>
> should then become illegal and must be rewritten as
>
> ---
>  int myFunc(Args...)(Args args)
>    if (Args.length > 2)
>    do { ... }
> ---
>
> I doubt that's going to happen, though (too much code 
> breakage), and I also don't like it. Simply drop the `do`.

I tend to agree. I think the grammar for `out` contracts is still 
murky, though, because the normal existing case is:

OutStatement:
    out ( Identifier ) { OutContractsBody }
    out { OutContractsBody }

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 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??)