On Friday, 23 June 2017 at 18:42:55 UTC, Steven Schveighoffer
wrote:
On 6/23/17 2:24 PM, Moritz Maxeiner wrote:
On Friday, 23 June 2017 at 17:31:15 UTC, MysticZach wrote:
[...]
Yeah, my take is that the grammar for `assert`s applies to
the new syntax as well. If the grammar for asserts is this:
AssertExpression:
assert ( AssertParameters )
... then the grammar for the new syntax is:
InExpression:
in ( AssertParameters )
OutExpression:
out ( ; AssertParameters )
out ( Identifier ; AssertParameters )
I'm all for this syntax, just one spec/implementation question:
If the new contract syntax (formally) shares grammar rules
with assert, won't that cause more work for people who want to
update the assert syntax later (since they will have to take
contracts into account)?
No. Asserts are the meat of in/out contracts, these are
actually asserts. Anything you do to the assert grammar should
be done here as well.
I'm not sure I get what you mean here: Asserts are just one
possible implementation of contract checking; this new syntax
explicitly decouples contract specification from contract
checking (semantics), opening the way for future DIPs addressing
such things as changing contract checking from assert to a
different system and/or moving contract checking from the callee
to the caller transparently. My worry is that having contract
specification and contract implementation share grammar rules
leaves them artificially coupled, though I don't know enough
about the compiler internals to know for sure: That's the essence
of my question.
