DIP 1002 (TryElseExpression) added to the queue

[Andrei Alexandrescu via Digitalmars-d]

On 9/27/16 11:30 AM, Dicebot wrote:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md
>
> PR: https://github.com/dlang/DIPs/pull/43
>
> Abstract:
>
> In Python, the try/catch/finally syntax is augmented with an additional
> clause, termed else. It is a fantastically useful addition to the
> conventional syntax. It works like this:
>
> ```
>     try:
>         do_something()
>     except Exception as e:
>         pass # Runs when an error inheriting from Exception was raised
>     else:
>         pass # Runs when no error was raised
>     finally:
>         pass # Runs unconditionally, evaluates last
> ```

Thanks for the submission. I made on pass through the document and it 
needs some work.

* Please remove colloquialisms. Characterizations such as "fantastically 
useful" are unlikely to be a convincing motivator and have no place in a 
DIP.

* The motivation section should showcase examples that currently are not 
possible or are contorted in D, followed by their alternative 
implementation using the proposed feature. At best, the example would be 
taken from existing code (e.g. found in dub, phobos, etc). Next best is 
code that defines a plausible artifact.

* The motivation section should also hypothesize on why the feature did 
not get traction in other languages than Python (Java, C++, C#). Also, 
it would be useful to show why D does need the feature even though it 
already has richer exception handing mechanisms by means of "scope".

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

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

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

* The example by Jack Stouffer should be also shown translated in 
current and proposed D.

* The example with "do_a_thing()" etc. is superfluous because it does 
not illustrate why one would want to "write code like this". Please 
focus on examples that are meaningful and easy with the feature, 
difficult without.

* My understanding is the last example (D rendition) can be expressed 
like this:

scope(exit) do_this_always();
bool success;
try
{
     do_a_thing();
     success = true;
}
catch(Exception exception)
{
     handle_error();
}
finally
{
    if(success)
    {
        depends_on_success_of_thing();
    }
}

There are further simplifications if it is known that handle_error() 
finishes the flow (by either throwing or an early return). Again, 
motivating examples would at best show that this pattern is frequent 
enough and awkward enough to justify the language addition.


Andrei