On Friday, 23 June 2017 at 20:27:58 UTC, MysticZach wrote:
On Friday, 23 June 2017 at 20:03:17 UTC, Moritz Maxeiner wrote:
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 agree. I can understand wanting to pass in/out violations
to a different handler behind the scenes. But I don't see why
that should affect the grammar.
Because coupling the new contract syntax and assert syntax in
the grammar means that changing assert syntax will affect the
new contract syntax (when it shouldn't, as they are
semantically decoupled).
By default, I assume they will not be semantically decoupled,
that they will all just use regular asserts. I think the
consistency the assert grammar will bring is worth a whole lot,
as once it is understood in one place, it is understood
everywhere. That's why it's so easy for Timon to implement, for
example, because the assert logic is already available. So, for
me to be convinced that the the grammar for in/out contracts
should be different, I'd have to see a clear and compelling use
case. What exactly did you have in mind?
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.
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 would go further and say that having consistency among all
types of contracts is valuable enough to be worth sacrificing a
considerable amount of flexibility in the grammar, even if a
compelling use case were presented.
I'm not sure what you're getting at here. With the proposal Timon
implemented we have the following:
- The older, flexible contract syntax, which essentially only
provides contract "shells" that you have to fill with your own
preferred contract implementation (for which asserts are
typically used)
- 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
- Asserts as a D builtin for condition checking (*not* a type of
contract)
In any case, it's merely a concern about future work load. If
asserts receive an overhaul, whoever does that will have to
(potentially) deal with it, I guess.
