Extended switch statement

[lerno]

Something I’ve been considering is an extended switch statement that is a structured if-else. So consider something like this:

Code: [Select]

switch (x) {
  case x > 200: return 0;
  case x < 2:
     small_x_warning();
     break;
  case 0:
     ....
  case x > y && a < 1:
     ...
}

So it’s a glorified if-else actually. It has better readability over if-else though.

I’m thinking about some other things:

• In the code above x is explicit i conditionals, but that does not make sense for switch (foo()) {...}. However using ”broken” expressions is harder to parse and sometimes impossible. For simple cases we can do ”case >100:” but what about the case of x > 10 && x < 20? It can’t be expressed that way.
• A solution to the above is to allow the switch to introduce switch scoped variables: switch (int i = foo()) { ... }. Multiple variables could be permitted: switch (int i = foo(); int j = bar()) {}
• If using (2) we need to decide whether additional variables could skip initialization if they aren’t used in the case.
• I think there is a sweet spot between the plain switch and full pattern matching, especially when dealing with ranges and matching strings.

Has anyone given this any thought?

I think C2 should certainly /evolve/ switch-case a bit. But how far and if it should be a completely new statement type or not - that’s something I’m unsure of.

The main two use-cases for me to replace (1) long if-else chains (2) switch-case where we really want ranges instead single numbers and often need to use if-else instead of switch.

[bas]

While there are a zillion things we can change about C2, the idea is that C2 is an evolution of C.

While changes like the binary operator precedence and default switch break are real improvements, I feel
that many other changes (like this one) are just that: changes. It's not really better/worse, just different.
On the roadmap are some (big) outstanding issues that really have to be designed, like a macro system
and cast operator syntax among others. Any other changes just make the language more different than
C. And since C is still used after 40 years, the core must be good..

This also goes for many other ideas and change pitches as well. For me, the fun in C2 is improving the bad
part and leave everything else the same (as possible)..

[lerno]

First, a minimal change would be to simply allow ranges in switch statements, such as:

Code: [Select]

switch (x) {
  case 1 .. 10:
     ...
  case 11 .. 100:
     ...
}

Secondly, I think it's a more constructive way to work by actually discussing how a proposal should look if adapted to C, rather than to dismiss it early because it doesn't feel like C.

I know it is tempting to dismiss this altogether, but if we have a proposal that looks like suitable for C, it's easier to both determine whether it is an evolution or not (i.e. sufficiently small change) and if worthwhile AND to have something to refer to later on when similar proposals inevitably show up.

Finally, its a good exercise "translating" the proposal to a useful form. I would argue the same for the error proposal: first see if it can be molded into something less ugly then decide whether it should be dismissed or not.

The limited switch IS a C deficiency, just like the limited error handling, header files, preprocessor macros etc. In order to see if there's an evolutionary way out of it, an evolutionary proposal should be made and I'm submitting incomplete proposals exactly so that it's more inviting to come and offer counterproposals and changes. The incompleteness is completely deliberate.

So again, I would like to discuss how it should look, then decide if that is useful enough to be considered for inclusion. Not dismissed in its incomplete state.