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
