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? My naive assumption is
that any improvement in the in/out grammar would also apply to
asserts, and 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.