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

[Enamex via Digitalmars-d]

On Sunday, 25 June 2017 at 17:20:51 UTC, Timon Gehr wrote:
> On 25.06.2017 17:46, Petar Kirov [ZombineDev] wrote:
>> On Sunday, 25 June 2017 at 12:10:02 UTC, Timon Gehr wrote:
>>> On 25.06.2017 13:37, Andrei Alexandrescu wrote:
>>> out(result){ assert(result > 0); } // exists
>>>
>>> out result => assert(result > 0) // more of the same
>>>
>>> out(result; result > 0) // better
>> 
>> out result => result > 0 // not much worse
>
> out(result; result > 0, "worse enough")
>
> Also, what Guillaume said.

Why do we need to name the result at all?

Any conflicts with using
`out(out > 0, "message")`
or
`out(return > 0, "message")`?
Or even
`out(someCond($), "message")`?

So using either `out` or `return` or `$` or whatever to always 
refer to the return value of the function. Just something that's 
already relevant and used instead of `__result`.

This could even be naturally extended to having an implicitly 
declared 'result' variable for functions (which could help in 
optimizations maybe? Something like always having NRVO possible) 
called `out` or `return`.

R foo(Args...)(Args args) {
     out(return > bar && ensured(return), "foo() fudged its 
return");
     // ...
     return = blah;
     // ...
     return.quux(var);
     static assert(is(typeof(return) == R)); // of course; this's 
old syntax
}