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.
