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

[Solomon E via Digitalmars-d]

On Friday, 23 June 2017 at 04:08:39 UTC, MysticZach wrote:
> On Friday, 23 June 2017 at 00:17:23 UTC, Steven Schveighoffer 
> wrote:
>> int foo()
>> out(result)
>> {
>> }
>>
>> what does this mean? Does it mean assert(result) on the out 
>> contract, or this is the old form of out?
>>
>> If we didn't have contract syntax already, and many existing 
>> code bases that use it, I'd say this would be the way to go.
>
> The current grammar is:
>
> OutStatement:
>    out ( Identifier ) { Statement }
>    out { Statement }
>
> So one way out is simply to demand that there be more than just 
> an identifier when checking in the new way. So you'd have to 
> require more tokens, e.g.`out(result !is null)` instead of just 
> `out(result)` in order for the parser to easily distinguish 
> between the two. It's a little messy. On the other hand, 
> requiring two sets of parens is clean, but ugly. So it's a 
> choice between ugly and messy, unless someone comes up with 
> something more elegant.

What I expected from my impression of existing D syntax was that 
something like this might be coming up:

T foo(T)(T x, T y)
     in (x > 0, y > 0)
     out (r; r > 0)
{
     return x % y + 1;
}

`out ()` has syntax similar to `foreach` and `for`, allowing 
mentioning something about the return type, or unpacking a return 
value, then testing it. (When there's no semicolon, an `out` 
block follows.)

`in ()` has syntax similar to an initializer for an array of 
`bool`, so that which condition failed can be given an index for 
generating error messages.

Not because it's elegant, but because it's complicated. It 
provides some features that were asked for in this thread and in 
some comments on DIP 1003, plus more possibilities.

I don't see where this breaks any existing D syntax, but maybe 
this sort of complication should be reserved for D++.