DIP 1002 (TryElseExpression) added to the queue

[Steven Schveighoffer via Digitalmars-d]

On 9/28/16 4:18 PM, pineapple wrote:
> On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
> wrote:
>> The more I think about this submission, I feel like the benefits are
>> quite slim.
>
> This is not and was not intended to be a glorious, incredible addition
> to the language. It is meant to shove D a couple inches further in the
> direction of modern programming constructs. Everywhere a programmer can
> use `else` instead of mucking about with a boolean success flag

The main question to answer is how big is this "Everywhere". I've never 
needed it. This obviously isn't proof against, but the situation we are 
solving here seems very small. Is it worth adding a construct to the 
language and it seems here we are going to break valid code that already 
uses else after catch to mean something else?

>
> On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
> wrote:
>> For example, should it be valid to use "else" without a catch?
>
> Yes.

Again, try {this} else {that} looks like "try this if it works, else 
that", which is not what this really does. else only reads right if it 
follows catch.

>
> On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
> wrote:
>> The boolean to indicate an exception was thrown is cumbersome, but not
>> horrible. Having the compiler manage the boolean may make this cleaner
>> (e.g. finally(bool thrown)), I like it better than the else suggestion.
>
> I think this would be an improvement over the current exception
> handling, but `else` is a pre-existing concept and making `finally`
> optionally accept a boolean this way tosses convention on its head, and
> not in a way I think is desireable. If what you're looking for is a
> clean solution, `finally(bool)` is definitely not it.

the pre-existing concept may work for Python, but not be OK for D (i.e. 
breaks valid code). The boolean concept is how you would implement it by 
hand, why does this toss it on its head? In fact, any code that requires 
this kind of flow already uses this mechanism, and can basically be 
updated to use the new concept by simply removing a few lines and 
changing finally to finally(bool).

> Moreover, Idan's suggestions about scope sharing make sense to me and I
> don't think his line of thinking would be compatible with doing it the
> way you suggest.

Declaring variables that you need in the right scopes is pretty 
straightforward. Having scopes magically continue around other separate 
scopes (catch scopes) doesn't look correct. I get why it's desired, but 
it doesn't look clean at all.

-Steve