DIP 1002 (TryElseExpression) added to the queue

[Andrei Alexandrescu via Digitalmars-d]

On 9/28/16 7:17 AM, pineapple wrote:
> These were not documented as a requirement anywhere that I saw. I'd have
> been happy to comply, if I had known this was the practice.

Yah, we're also learning the ropes. Bear with us - this is one of the 
first DIPs using the new flow.

> I don't know enough about how D is compiled to speak meaningfully about
> implementation details.

I'll formalize this in DIP guide, but some level of implementation 
discussion is necessary - the more, the better. It has happened in the 
past (in various languages) that things that seemed sensible were 
proposed and partially implemented without a clear handle on 
implementation issues. It would improve the DIP a lot if you 
collaborated with somebody fluent with implementation issues.

> I am clearly not the only one who's convinced this is a useful feature.
> I welcome you or anyone else who can more effectively express the idea
> to make their own contributions to the DIP.

> If catch and finally don't continue the scope of try, then neither
> should else.

Then I'd say the DIP should discuss the relative advantages and 
disadvantages compared to the incarnations in other languages. My 
understanding is it is important for the "else" branch to continue work 
initiated in the "try" branch. How well does the feature fare without 
this amenity? It's the kind of question the DIP should address.

> That said, it might be preferable if they all did continue try's scope.
> But this would be a distinct and separate change.

The short answer is that will never happen.

>> * The "Breaking changes" section should include how the following
>> change in semantics would be addressed. Consider:
>>
>>   try
>>     if (expression)
>>         try { ... }
>>         catch (Exception) { ... }
>>     else { ... }
>>   finally { ... }
>>
>> This code is currently legal and binds the "else" clause to the "if"
>> and the "finally" to the first "try". The proposed feature will bind
>> the "else" and the "finally" to the second try and then probably fail
>> to compile because there is no "catch" or "finally" matching the first
>> "try".
>
> This possibility hadn't occurred to me. Is that really legal?
>
> If so, I'd argue the old behavior should be maintained and also that
> people shouldn't write such ambiguous code.

For a DIP to be successful, its authors need to be fluent with 
syntactical matters and be able to enumerate them and how they are 
supposed to be handled ("else" also works with "static if", "version", 
and since DIP 1002 itself, other "try" statements).


Andrei