DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[MysticZach via Digitalmars-d]

On Monday, 31 July 2017 at 09:55:22 UTC, Nick Treleaven wrote:
> This is subjective. If you put `do` on the end of the line, it 
> is trivial:
>
> in(x > 4)
> out(works)
> out(r; r.test)
> out(flag) do
> {
>   // body
> }

The common case is for `out` contracts to test for the return 
variable. Something like 90% will therefore look like:

int fun(int x)
out(r; r > 0)
{

}

So it's the uncommon case we're trying to solve for. Requiring 
`do` in precisely one case, which is the rare case in which the 
`out` test has only one identifier, and therefore can't be 
disambiguated from existing `out` contracts, is a solution to 
that problem. It's seems like a complicated one. To me, it's 
simpler to simply require the `;` because it's the uncommon case 
to begin with, and everyone will know what it means because 
they'll be used to seeing `out(r; r > 0)`.

That said, `do` can solve the loophole with the alternative 
ambiguous syntax. For example:

int fun(ref int x, ref int y, ref int z)
out(x)     // fine, followed by another contract
out(y != 0) // fine, multiple tokens, unambiguous
out(z) do   // fine, followed by `do`
{
}

If you forget to add the `do` there is an inevitable parsing 
error, so it's not that bad even in the worst case. The error can 
be fixed by changing `out(z)` to `out(z != 0)`, or to `out(z) do` 
as you suggest. `do` is only going to be valuable in that one 
case, though. I'd say it depends where the language designers 
want to pay the cost of solving the problem. Either pay it up 
front with the ugliness of the foreach syntax, or pay it in 
complexity with the different cases of the ambiguous syntax. 
Because it's a programming language and not a sports car, I'd 
probably  choose the consistency of the foreach syntax over the 
attractiveness of the ambiguous syntax. But there's no clear 
winner, IMO.