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

[Solomon E via Digitalmars-d]

On Friday, 23 June 2017 at 21:14:47 UTC, MysticZach wrote:
> On Friday, 23 June 2017 at 20:49:35 UTC, Moritz Maxeiner wrote:
> ...
>> I'm not sure what you're getting at here. With the proposal 
>> Timon implemented we have the following:
>> - the newer, decoupled contract syntax that separates contract 
>> specification and implementation from each other; Timon's 
>> implementation uses asserts as the internal contract 
>> implementation AFAIK
>
> Not exactly. It actually _couples_ `in` expressions with assert 
> expressions. In essence it just lowers
>
> int fun(int a)
> in(a)
> {
> }
>
> ...to:
>
> int fun(int a)
> in { assert(a); }
> {
> }
>
> This is a sensible default. In the future, some logic could be 
> added to provide a hook to a different implementation of the 
> `in` function, so that it would lower instead to:
>
> int fun(int a)
> in { __userDefinedInContract(a); }
> {
> }
>
> But I suspect the vast majority will stick with the default.

I think my proposal to add another use of semicolon in 
parentheses, like `foreach` or `for` but not the same as either, 
was needlessly complicated.

in (a)
out (result) (a)

as syntax sugar where each (a) lowers to
{assert(a);}
and in future can lower to something else, to renovate contract 
implementation

That's so much easier, in every way.