DIP 1002 (TryElseExpression) added to the queue

[pineapple via Digitalmars-d]

On Thursday, 29 September 2016 at 11:45:42 UTC, Marc Schütz wrote:
> On Wednesday, 28 September 2016 at 22:12:27 UTC, Idan Arye 
> wrote:
>>     Foo foo;
>>     try {
>>         foo = Foo();
>>     } catch (FooCreationException) {
>>         // ...
>>     } else {
>>         foo.doSomethingWithFoo();
>>     }
>>     // foo exists here - it could be initialized, it could be 
>> not...
>
> And `Foo` could have `@disabled this()`, so you simply _can't_ 
> declare it without initializing it (or use the dirty `Foo foo = 
> Foo.init` workaround). But of course, that's a corner case...

This is actually 100% of why I think scope sharing between `try`, 
`catch`, `finally`, and `else` statements deserves consideration. 
`Foo` should not have to be mutable or rebindable in order to 
handle its success or error state in the other statements.

On Thursday, 29 September 2016 at 12:24:31 UTC, Andrei 
Alexandrescu wrote:
> Thanks, Jack. Here I'm solely focused on making DIP1002 
> stronger so I've sent a number of suggestions that I believe 
> would improve the proposal. Although you are free to argue here 
> that in fact the proposal already is strong enough, this is not 
> a "minimal requirements" setup in which a DIP is good to go as 
> long as it passes a checklist. The demand here is elastic; the 
> stronger the DIP, the better. Once submitted, if rejected, the 
> only way to propose a similar feature is by authoring a new 
> proposal with a completely novel perspective. So official 
> review is an important milestone with a high bar. -- Andrei

I do appreciate the feedback, by the way, which is why I 
submitted the recent PR.

One thing I'd point out: You rewrote my rewritten examples 
without using `else`, but as was stated immediately before I 
listed those examples:

> The best examples of code that can be more elegantly written 
> using this
>`else` clause occur in application logic, such as the example 
>described
> above where a values were read from sensors and saved to a 
> server. However,
> there are a few places in Phobos that could be more readable 
> and not
> require success flags if this new syntax were employed.