On Friday, 23 June 2017 at 18:03:26 UTC, Timon Gehr wrote:
> On 23.06.2017 18:21, H. S. Teoh via Digitalmars-d wrote:
>> [...]
>> 
>
> Agreed. Implementation:
> https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax
>
> (At most one contract of each type is supported. It is not very hard to implement multiple contracts, but this requires touching semantic analysis.)

Holy ***. I set aside some time this weekend to try implementing this myself as an exercise, but oh well. Thanks!

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)?

On Friday, 23 June 2017 at 18:06:34 UTC, Timon Gehr wrote:
>
> Because it cannot be parsed greedily. See:
> http://forum.dlang.org/post/beovehhmoxzuoepterzz@forum.dlang.org

I see what you're saying. I don't think I really grokked it when you posted the example yesterday.

And also it is consistent with the for syntax, which requires semi-colon, even if blank.

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.

-Steve

On 23.06.2017 06:27, MysticZach wrote:
> On Friday, 23 June 2017 at 00:17:23 UTC, Steven Schveighoffer wrote:
>> We can call that contextual "keyword" result. Doesn't have to be a keyword, just the implied return value symbol name.
> 
> Another problem is that any given contextual reserved identifier you choose will run the risk of shadowing other variables. `result` could easily already be defined in an outer context. A solution to this is to use a variable starting with `__`, as those are the existing way of defining reserved identifiers. Maybe `__result`?
> 
> 

out{ assert(__result>0); } actually works already, but I think it is undocumented. ;)

On Friday, 23 June 2017 at 18:20:23 UTC, Moritz Maxeiner wrote:
> On Friday, 23 June 2017 at 18:03:26 UTC, Timon Gehr wrote:
>> On 23.06.2017 18:21, H. S. Teoh via Digitalmars-d wrote:
>>> [...]
>>> 
>>
>> Agreed. Implementation:
>> https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax
>>
>> (At most one contract of each type is supported. It is not very hard to implement multiple contracts, but this requires touching semantic analysis.)
>
> Holy ***. I set aside some time this weekend to try implementing this myself as an exercise, but oh well. Thanks!

I know! I'd say it'll take me a good deal longer to rewrite the DIP than he's taking to implement it!

On Fri, Jun 23, 2017 at 06:57:57PM +0000, MysticZach via Digitalmars-d wrote:
> On Friday, 23 June 2017 at 18:20:23 UTC, Moritz Maxeiner wrote:
> > On Friday, 23 June 2017 at 18:03:26 UTC, Timon Gehr wrote:
[...]
> > > Agreed. Implementation: https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax
> > > 
> > > (At most one contract of each type is supported. It is not very hard to implement multiple contracts, but this requires touching semantic analysis.)
> > 
> > Holy ***. I set aside some time this weekend to try implementing this myself as an exercise, but oh well. Thanks!
> 
> I know! I'd say it'll take me a good deal longer to rewrite the DIP than he's taking to implement it!

Yeah!  Kudos to Timon for the quick implementation!  This will increase the odds of this DIP being accepted, I'm sure. :-)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

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 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.

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.

On Friday, 23 June 2017 at 19:38:11 UTC, MysticZach 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 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).