Programming languages with switch control flow statements typically seem to either (1) make it so that switch statements have fall through behavior (which is often error prone, since it is the less common use case) or else (2) force switch statements to never fall through. Neither of these choices is the wisest choice though.
There is no actual reason why a programming language should be forced into being artificially handicapped by either of these variants’ weaknesses. Instead, the programming language could simply make two different keywords available for switch statements, in such a way as to clearly indicate which behavior will be the result.
For example, if a programming language’s existing version of switch is the kind that falls through, then a new keyword named something obvious like no_fallthru_switch can be added to the language and designed to not have any fall through behaviors.
Similarly, in the opposite, case, if a programming language’s existing version of switch is the kind that never falls through, then a new keyword named something like fallthru_switch can be added to the language and designed to add fall through support for handling situations where it provides some benefit, which (while rarer) do certainly exist and have merit.
In fact, in general it seems like programming language designers are often overly reluctant to add new keywords, when really adding a new keyword is often actually the best pragmatic choice. Trying to cram new features onto preexisting syntax in a language too often can force a language designer to make poor trade-offs or handicap the language when there is no actual reason to do so if one thinks more broadly and more naturally.
Many debates about whether things should be done one way or another can be trivially instantly eliminated by simply admitting that both approaches have their merits in different contexts and then creating separate obviously distinguished features to fill those naturally and logically separate roles.
Another option, similar to the above options, would be to have both cases explicitly distinguished so that even someone new to the language or who hasn’t used in it a long time could always tell which was which instantly. For example, you could have both no_fallthru_switch and fallthru_switch in the same language, instead of having switch and no_fallthru_switch or switch and fallthru_switch, where switch is defaulting to different meanings.
Another option (probably better than the above ones actually) would be to put the “switch” part of the above keywords first, as a prefix instead of a postfix (aka suffix), so that the keywords read more like a namespace in a sense (also thereby enabling better auto-complete). Thus, for example, you could do switch_no_fallthru and switch_fallthru instead of the above equivalents.
Yet another approach, for those who give more weight to concision than to making the connection to the existing switch concept completely obvious, is that one could simply introduce a new keyword entirely, to account for the missing variant. For example, if switch is already in the language then some other word, such as select, could be added. Thus, for example, in C and C++ one could have select mean a no fall-through version of switch. That would sound pretty natural and would be less verbose.
Any of these approaches is good though and is quite a significant improvement over only having one variant or the other available.
Another idea is that you could also provide pattern_match as a separate keyword if you want to add pattern matching onto an existing language that doesn’t have switch statements that support that kind of more advanced usage and such.
Also, just because you already have (or are going to add) pattern matching support into a language though doesn’t mean that you should get rid of the older simpler variants though. There is value in limitation. When a user knows that a keyword or feature has a more limited set of possible behaviors, then that can make it easier to reason about or to anticipate what one will read next. This is analogous somewhat to how const constrains a variable in C or C++ but very often makes it much easier to reason about the related code.
One should not be too overeager to force everything into one “best” way of doings things. Sometimes that has merit, but is wise to be cautious and pragmatic and to leave options open in most cases.
I also want to say that I often find myself disconcerted by how often design choices on these kinds of things end up being decided primarily by inertia, with people essentially automatically dismissing anything that isn’t already a part of the system they are already used to, not based on any kind of real merit but just based on a kind of knee-jerk reaction.
Indeed, it wouldn’t surprise me at all if somewhere somebody reacts to this post in exactly that way, in the oh-so-typical hand-wavy unimaginative mocking brain-dead kind of way that I have so often seen over and over in my life, even in cases where the merits of an idea is extraordinarily and blatantly obvious.
That’s just how it is though sometimes. It’s much easier to imitate what is already popular mindlessly and to conform to that groupthink narrative than it is to think logically from first principles in any kind of genuine way, and so it is thus no surprise that progress can be so hard to achieve sometimes, even in the most trivial of cases such as this one for example.
Anyway, I hope you enjoyed this article. Live free and think free!
Have a great day/night/week/etc, as always, everyone! 😃