DIP 1002 (TryElseExpression) added to the queue

[pineapple via Digitalmars-d]

On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei 
Alexandrescu wrote:
> * Please remove colloquialisms. Characterizations such as 
> "fantastically useful" are unlikely to be a convincing 
> motivator and have no place in a DIP.
>
> * The "Description" section should be more detailed and less 
> casual. The grammar changes should be shown in a syntax similar 
> to the current grammar definition.

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.

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

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.

On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei 
Alexandrescu wrote:
> * I saw in the forum that the "else" clause is supposed to run 
> in the scope of the "try" statement, but that is not mentioned 
> in the proposal. Even though that is the semantics in Python, 
> that should be explicit in the document. The proposal should be 
> standalone and fully specified without knowing Python or 
> perusing external links.
>
> * The fact above (the "else" clause continues the scope of the 
> statement after "try") is surprising, considering that the 
> "catch" and "finally" clauses introduce their own scopes. The 
> irregularity may confuse users. If the "else" clause is defined 
> to introduce its own scope, it seems the advantages of the 
> proposal are diminished.

It was an idea that was raised, yes.

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

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

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