DIP 1002 (TryElseExpression) added to the queue

Idan Arye via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 28 08:23:58 PDT 2016


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


More information about the Digitalmars-d mailing list