On 6/23/17 3:51 PM, Moritz Maxeiner wrote:
On Friday, 23 June 2017 at 18:42:55 UTC, Steven Schveighoffer wrote:
On 6/23/17 2:24 PM, Moritz Maxeiner wrote:
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.
Moving the check from the callee to the caller wouldn't matter here, it
just defines when the asserts are called.
I don't think there's an issue here -- you can implement some other form
of checking if you wish, but it's going to be outside the language.
You can always still do in and out block syntax. Or is this DIP
proposing to do away with that? I didn't see any mention of deprecating
current syntax.
I view this improvement like short lambda syntax. When your lambda is
one expression, so much easier and convenient to use the => form. But
you can always reach for the multi-statement form if needed.
-Steve
