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

[Moritz Maxeiner via Digitalmars-d]

On Friday, 23 June 2017 at 18:42:55 UTC, Steven Schveighoffer 
wrote:
> On 6/23/17 2:24 PM, Moritz Maxeiner wrote:
>> On Friday, 23 June 2017 at 17:31:15 UTC, MysticZach wrote:
>>> [...]
>>>
>>> Yeah, my take is that the grammar for `assert`s applies to 
>>> the new syntax as well. If the grammar for asserts is this:
>>>
>>> AssertExpression:
>>>   assert ( AssertParameters )
>>>
>>> ... then the grammar for the new syntax is:
>>>
>>> InExpression:
>>>   in ( AssertParameters )
>>>
>>> OutExpression:
>>>   out ( ; AssertParameters )
>>>   out ( Identifier ; AssertParameters )
>> 
>> 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.