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

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
> On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
> wrote:
>> int myFunc(Args...)(Args args)
>>   if (Args.length > 2)
>>   in (args[0] != 0)
>>   in (args[1] > 1)
>>   out (result => result > 0) { ... }
>> ---
>>
>> - in contracts take a parenthesis delimited bool expression
>> - out contracts take a parenthesis delimited bool function 
>> literal.
>
> `out` contracts would also have to account for the case where 
> they don't check the return value. This would confuse the 
> grammar a little in the case of function literals as boolean 
> expressions. A different possible grammar that wouldn't have 
> this problem is:
>
> OutStatement:
>     out ( IfCondition )
>     out ( Identifier ) ( IfCondition )
>
> plus the existing ones:
>
> OutStatement:
>     out BlockStatement
>     out ( Identifier ) BlockStatement

I may have spoke too soon. If the grammar were:

OutStatement:
     out ( IfCondition )
     out ( FunctionLiteral )

It might still work okay. A little hiccup in the semantics, 
figuring out that the first parameter to the function literal is 
meant to be the return identifier. Maybe it's not a big deal.