On Wednesday, 28 September 2016 at 11:17:05 UTC, pineapple wrote:
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.
I'm the one who suggested that, and I believe there is a very
good reason why `else`'s scope behavior should differ from
`catch`'s and `try`'s.
`catch` and `finally` should not continue `try`'s scope, because
they can run even when `try` did not finish successfully(that's
their purpose), which means the variables declared in `try` may
or may not be initialized in the `catch` and `finally` blocks.
For the same reason it's not useful to have them continue the
scope - you can't use the variables declared in them if you don't
know whether or not they have been initialized.
`else` is different - it is guaranteed to only execute if `try`
finished successfully, which means all variables in the `try`
block have had their initialization statements executed. Also,
it's actually useful to have it continue the scope, because one
may want to declare a variable in `try`(so they can `catch`
exceptions in it's initialization) but use it in `else`(so the
same exceptions in it's usage will bubble up).
This has little to do with Python's semantics. Python is an
interpreted language so it doesn't bother with scope rules for
control statements - either the initialization statement was
executed and the variable is initialized, or it wasn't and the
variable is not declared. D can not imitate this behavior...
