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

[Steven Schveighoffer via Digitalmars-d]

On 6/23/17 3:51 PM, Moritz Maxeiner wrote:
> On Friday, 23 June 2017 at 18:42:55 UTC, Steven Schveighoffer wrote:
>> On 6/23/17 2:24 PM, Moritz Maxeiner wrote:
>>> 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.

Moving the check from the callee to the caller wouldn't matter here, it 
just defines when the asserts are called.

I don't think there's an issue here -- you can implement some other form 
of checking if you wish, but it's going to be outside the language.

You can always still do in and out block syntax. Or is this DIP 
proposing to do away with that? I didn't see any mention of deprecating 
current syntax.

I view this improvement like short lambda syntax. When your lambda is 
one expression, so much easier and convenient to use the => form. But 
you can always reach for the multi-statement form if needed.

-Steve