Bug 3699 – Feature Request: while-else

It would be nice to add a while-else statement to the language. while ( Expression1 ) ScopeStatement1 else ScopeStatement2 may act like that: if ( Expression1 ) do ScopeStatement1 while ( Expression1 ); else ScopeStatement2 or like that: bool entered = false; while ( Expression1 ) { entered = true; ScopeStatement1 } if (!entered) ScopeStatement2 two of them has some problems. First one is more efficient but you must write the same expression twice. The second is more readable but there is an extra declaration and an extra cost. while-else is more readable and more efficient. someone can want a python like while-else statement. using while-finally syntax would be more suitable for that. while ( ... ) { ... if ( ... ) break; ... } finally ScopeStatement3 ... if break occures the ScopeStatement3 is not executed else it is executed once. But I think it is not necessary because we can provide that by using a simple goto statement instead of break. while ( ... ) { ... if ( ... ) goto label; ... } ScopeStatement3 label: ...

What should this do? if (c1) while (c2) stmt1 else stmt2 And in particular, how would you reconcile existing code with the new feature?

> What should this do? > > if (c1) > while (c2) > stmt1 > else > stmt2 > if (c1) { while (c2) stmt1 else stmt2 } It should do that of course. > And in particular, how would you reconcile existing code with the new feature? In such situations the compiler can warn the developer, perhaps it can be bound to -w switch. General the developers uses this form: if (c1) { while (c2) stmt1 } else stmt2 instead of: if (c1) while (c2) stmt1 else stmt2 D2 is in alpha status, isn't it. I see some changes on D2 that breaks code. You should decide whether the new feature is important and necessary enough to accept the risk of code breaks or not. I usually feel the need for that feature. an example on fetching rows from db: while (row = query.nextRow()) writeln(row); else writeln("no row"); It's really a nice feature. I think D should collect all the nice features itself.

(In reply to comment #2) > D2 is in alpha status, isn't it. I see some changes on D2 that breaks code. > You should decide whether the new feature is important and necessary enough to > accept the risk of code breaks or not. Yes. But an important goal of D has been the principle of least astonishment (for C programmers). That is, C code copied to D should either compile successfully, or fail spectacularly. This fails to follow those guidelines, and introduces silent changes in behavior.

(In reply to comment #3) > This fails to follow those guidelines, and introduces silent changes in behavior. Not silent, by giving a warning message. But we can solve this problem by several ways. 1) by giving priority to if. Examples: if (c1) while (c2) stmt1 else stmt2 will behave like this: if (c1) { while (c2) stmt1 } else stmt2 ---------------------- while (c1) while (c2) stmt1 else stmt2 will behave like this: while (c1) { while (c2) stmt1 else stmt2 } (2) in addition to (1) it can be standardized by the rule: the outermost else is belonging to the outermost while. Then: while (c1) while (c2) stmt1 else stmt2 will behave like this: while (c1) { while (c2) stmt1 } else stmt2 (3) in addition to (1) this type of ambiguities (which 'while' 'else' belongs to) can be forbidden then this will give an error while (c1) while (c2) stmt1 else stmt2 (4) using otherwise statement instead of else while (c1) stmt1 otherwise stmt2

(In reply to comment #4) > (In reply to comment #3) > > This fails to follow those guidelines, and introduces silent changes in behavior. > > Not silent, by giving a warning message. "Warnings are not a defined part of the D Programming Language." (http://digitalmars.com/d/2.0/warnings.html) IOW, warnings are not an option. > But we can solve this problem by several ways. If that creates inconsistencies, it will not be accepted. And the proposed solutions do.

(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > This fails to follow those guidelines, and introduces silent changes in behavior. > > > > Not silent, by giving a warning message. > > "Warnings are not a defined part of the D Programming Language." > (http://digitalmars.com/d/2.0/warnings.html) IOW, warnings are not an option. OK > > But we can solve this problem by several ways. > > If that creates inconsistencies, it will not be accepted. And the proposed > solutions do. I think giving priority to 'if' about 'else's solves all inconsistencies between existing code and the new feature. Or the radical solution: 'otherwise' ...

Four year old request. Can be discussed further on NG if required.

Thanks for cleaning up the list!

(In reply to comment #7) > Four year old request. Can be discussed further on NG if required. There are bugs that sleep in bugzilla for years just because no one has time or desire to fix them, but they are still valid. I have plenty of similar bugs in bugzilla. So closing down an issue just for lack of fixes is not a good idea. And a Python-like "else" clause of while/for/foreach is nice. You can replace code like: bool ok = true; foreach (...) { ... if (cond) { ok = false; break; } } if (!ok) { ... } With: foreach (...) { ... if (cond) break; } else { ... } Reopened until we have a true decision.

I don't think we can keep all proposals opened on the off chance one may be acted upon at some point. At some point we need to make a decision.