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.
