DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

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.