4 ms·

Not a big fan. Consider that: if( a ) { if( b ) { if( c ) breakelse; } else {

Not a big fan. Consider that: if( a ) { if( b ) { if( c ) breakelse; } else { // E2 } } else { // E1 } You wrote it, tested it and are happy. Then a year later other person is reworking the code due to changed requirements, deletes the E2 else block, and breakelse suddenly starts to jump into E1 else block. Especially bad if there's a page of code between breakelse and E2 block, and another page between E2 and E1. The proposed feature becomes a spooky action at a distance.

FeepingCreature 3y ago
That's true. However, you would rarely use nested-else blocks like that to begin with. The whole point is that you can avoid deep nested scopes.
- narnarpapadaddy 3y ago
  Would it be possible to restrict the use of breakelse only to if statements that contain an else?
  - FeepingCreature 3y ago
    Sure, and I agree it's kind of misleading, but half my motivation is to skip past an optional if block. I think of it as 'else' being there, but empty.
jeroenhd 3y ago
This is a good point. I think it can be made more readable by forcing labeled else statements, like: 'outer: if a() { 'inner: if b() { if c() { breakelse 'inner; } if d() { breakelse 'outer'; } } else { // E2 } } else { // E1 } This way, you can trigger syntax errors when someone refactors the code. It's not particularly pretty, but it does communicate the control flow better than simple gotos in my opinion. Thinking about this, I imagine there's even a way this could be made useful: in languages where if/case/match statements are expressions, you could make breakelse an expression that returns the result of the else branch. On the other hand, perhaps a "checkagain" statement to re-evaluate the if statement once would be better for that: if isInDatabase(id) && isProfileComplete(id) { return db.fetchUser(id); } else { api.autocompleteUser(id); let retry = checkagain; if retry != None { db.update(retry); } } Honestly I think it's ugly as hell but I think there could be something here if someone competent at designing languages would take a look at this.

FeepingCreature 3y ago

That's true. However, you would rarely use nested-else blocks like that to begin with. The whole point is that you can avoid deep nested scopes.

narnarpapadaddy 3y ago
Would it be possible to restrict the use of breakelse only to if statements that contain an else?
- FeepingCreature 3y ago
  Sure, and I agree it's kind of misleading, but half my motivation is to skip past an optional if block. I think of it as 'else' being there, but empty.

jeroenhd 3y ago

This is a good point. I think it can be made more readable by forcing labeled else statements, like: 'outer: if a() { 'inner: if b() { if c() { breakelse 'inner; } if d() { breakelse 'outer'; } } else { // E2 } } else { // E1 } This way, you can trigger syntax errors when someone refactors the code. It's not particularly pretty, but it does communicate the control flow better than simple gotos in my opinion. Thinking about this, I imagine there's even a way this could be made useful: in languages where if/case/match statements are expressions, you could make breakelse an expression that returns the result of the else branch. On the other hand, perhaps a "checkagain" statement to re-evaluate the if statement once would be better for that: if isInDatabase(id) && isProfileComplete(id) { return db.fetchUser(id); } else { api.autocompleteUser(id); let retry = checkagain; if retry != None { db.update(retry); } } Honestly I think it's ugly as hell but I think there could be something here if someone competent at designing languages would take a look at this.