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

[Patrick Schluter via Digitalmars-d]

On Thursday, 22 June 2017 at 22:12:57 UTC, MysticZach wrote:
> On Thursday, 22 June 2017 at 21:56:29 UTC, Timon Gehr wrote:
>> On 22.06.2017 23:51, MysticZach wrote:
>>> On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
>>>>> The whole double parentheses is a bit ugly to me. Is there 
>>>>> any problem with
>>>>> out(return > 0)
>>>>> instead of
>>>>> out(r) (r > 0)
>>> 
>>> I'm sorry, I didn't read closely. I think that's just asking 
>>> for trouble, wanting to use `return` as an identifier. Timon 
>>> found a specific reason why, but in general contextual 
>>> keywords are frowned upon for precisely this type of 
>>> ambiguity in the meaning of the code.
>>
>>
>> (It's not a contextual keyword. A contextual keyword is an 
>> identifier that is reserved in some contexts but not others.)
>
> I would argue that the above suggestion promotes `return` 
> precisely that way. It's now an identifier in precisely that 
> one context, but is reserved as a keyword in all other 
> contexts. Not sure what to call it. But we're a little off 
> topic, as we both agree that the above solution to the double 
> parens isn't viable, right?

It's not an identifier, means syntactically it is still a 
reserved keyword but you are right that it would be semantically 
very different. In normal contexts it's a flow control statement 
in that context it is an alias to a value with no influence of 
the program flow. Would be really annoyingly contradictory.