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

[MysticZach via Digitalmars-d]

On Friday, 23 June 2017 at 20:49:35 UTC, Moritz Maxeiner wrote:
> Normal usage of the new syntax? If asserts later on get a 
> (possibly breaking) syntax overhaul that will affect (and 
> forward breakage to) the contract syntax, as well, if it uses 
> the same compiler infrastructure.

I believe this fear is irrational. A breaking change to the 
assert syntax would be extremely stupid. Imagine how much code 
would break if there were a breaking change to `assert`! The only 
possible changes to it must be additive.

>> My naive assumption is that any improvement in the in/out 
>> grammar would also apply to asserts, and vice versa.
>
> Why should it? Contracts are not asserts or vice versa.

I 95% disagree. As far as I can tell, they are _very_ similar. 
The only difference I can see is that when you violate an `in` 
contract, the exit message should point to the caller instead of 
the callee as the source of the problem. Beyond that, they seem 
like little more than glorified `assert`s. I think their greatest 
benefit is in helping the programmer read and understand the 
logic of the program, rather than in anything the compiler can do 
with them.

> 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.