• Quirin Schroll (66/66) Apr 10 One of the first DIPs that had been proposed asked for a
• Nick Treleaven (14/25) Apr 10 Which languages?
• Dukc (19/27) Apr 10 I'm not too eager about this. With the prefixes, the `else`s are

Quirin Schroll <qs.il.paperinik gmail.com> writes:

One of the first DIPs that had been proposed asked for a 
Python-like `else` on `try` (for the case when no exception is 
being thrown). Some newer languages have loop constructs with a 
block that’s being executed when the loop hasn’t been entered and 
is skipped by `break` in the loop. Because of the dangling `else` 
problem, my idea to fix this is prefixing the `else` keyword with 
the construct keyword, e.g. `try else` or `while else`.

```d
while (cond())
{
     action();
}
while else
{
     fallback();
}

for (; cond();) { } for else { }

foreach (x; xs) { } foreach else { }

do {} while (cond()); do else { }
// Note: The `do else` block is unreachable unless it contains a 
label and a `goto` statement leading to it.
```

I’m not sure if `do`―`while`―`do else` is worth it. On the other 
hand, consistency.

```d
try
{
     int x;
     {
         int y;
         risky(x, y);
     } // scope of y ends
}
try else
{
     cheer(x); // `x` still in scope
     // cheer(y); // Error: No `y` in scope
}
catch (Exception e)
{
     fallback();
}
finally
{
     cleanup();
}
```
Local variables declared in the `try` part that are in scope at 
the end of the `try` part will be in scope in the `try else` 
part. Their scope covers the `try` and `try else` part. One can 
easily restrict all locals in the `try` part using `try {{ … }} 
try else { }`.


For `if`, essentially, `if else` would not be allowed (use just 
`else`), however, for `static if`, `if else` is the same as `else 
static if`, allowing you to skip endless `static` keywords in a 
long sequence of alternatives:
```d
static if (cond1())
     …
if else (cond2())
     …
if else (cond3())
     …
else
     …
```

Nick Treleaven <nick geany.org> writes:

On Friday, 10 April 2026 at 15:18:56 UTC, Quirin Schroll wrote:
 One of the first DIPs that had been proposed asked for a 
 Python-like `else` on `try`

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1002.md

 (for the case when no exception is being thrown). Some newer 
 languages

Which languages?

 have loop constructs with a block that’s being executed when 
 the loop hasn’t been entered and is skipped by break in the 
 loop.

Do you mean when the condition is *first* evaluated and evaluates 
to false, the else block runs, otherwise it doesn't? That would 
be inconsistent with the [python for/else 
definition](https://www.w3schools.com/python/gloss_python_for_else.asp):

 The else keyword in a for loop specifies a block of code to be 
 executed when the loop is finished
 Note: The else block will NOT be executed if the loop is 
 stopped by a break statement.

...
```d
do {} while (cond()); do else { }
// Note: The `do else` block is unreachable unless it contains a 
label and a `goto` statement leading to it.
```
Why isn't the `else` block run when `cond()` evaluates to false?

Dukc <ajieskola gmail.com> writes:

On Friday, 10 April 2026 at 15:18:56 UTC, Quirin Schroll wrote:
 One of the first DIPs that had been proposed asked for a 
 Python-like `else` on `try` (for the case when no exception is 
 being thrown). Some newer languages have loop constructs with a 
 block that’s being executed when the loop hasn’t been entered 
 and is skipped by `break` in the loop. Because of the dangling 
 `else` problem, my idea to fix this is prefixing the `else` 
 keyword with the construct keyword, e.g. `try else` or `while 
 else`.

I'm not too eager about this. With the prefixes, the `else`s are 
verbose enough that they are only a little better than

```D
if(cond()) do
{  //...
} while(cond()) else
{  //...
}
```

. Too little gain in expressive power to justify a new feature in 
my taste. Being a taste question though, if many people feel this 
is a significant improvement, I won't oppose.

If we decided to drop the prefixes and suffer the breakage from 
the dangling else problem, I think it would be worth it, were we 
to consider added language complexity as the only issue. However, 
considering D aims to work like C for constructs that compile in 
both languages, plus the breakage of old code, I don't think that 
would be a good idea overall either.