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

[Moritz Maxeiner via Digitalmars-d]

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.