5 ms·
a nitpick: a bit down the page there is stuff on the case syntax. The fact that "you can't have an empty break" is a good choice, but the fact that having two
by throwawaymaths 1y ago
a nitpick:
a bit down the page there is stuff on the case syntax. The fact that "you can't have an empty break" is a good choice, but the fact that having two cases do the same thing has syntax
case X:
case Y:
is footgun waiting to happen. I would strongly suggest the authors of C3 make stacking cases look like this:
case X, Y:
- fragmede 1y agoseems subtle to distinguish between case 3,4: for values 3 or 4, and case (3,4): for an array with the value [3,4]
- throwawaymaths 1y agooof. To me switch/case mentally implies constant time matching and routing, I wonder if that is the case (it could be if arrays have compile-time known length).
- lerno 1y agoYou have both in C3: switch (x) { case 0: ... case 1 + 1: ... } This will behave in the normal way. But you can also have: switch { case foo() > 0: ... case bar() + baz() == s: ... } In which case it lowers to the corresponding if-else.
- deleted 1y ago[deleted]
- norir 1y agoI am not a fan of this design in a low level language. The first version of switch does exactly one thing and is very clear. The second now is forcing me to think both about branching logic and control flow. I understand the surface level appeal of the syntax, but if I encountered code written with this feature in the wild, I would think something must have gone wrong in the program design.
- throwawaymaths 1y agoi think hlls sometimes distinguish between these situations with a different keyword.
- lerno 1y agoIt's very simple, the latter describes an `if-else` chain. No more complicated than that. Can you explain what your concern is?
- lerno 1y ago"case X, Y" works for 3-4 values, but for something longer problems accumulate: case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE: foo(); int y = baz(); Placing them on the next row is fairly hard to read case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE, AND_NUMBER_FOUR, AND_NUMBER_FIVE, AND_THE_LAST_ONE: foo(); int y = baz(); In C I regularly end up with lists that have 10+ fallthroughs like this, because I prefer complete switches over default for enums at least. case SOME_BAD_THING: case SOME_OTHER_CONDITION: case HERE_IS_NUMBER_THREE: case AND_NUMBER_FOUR: case AND_NUMBER_FIVE: case AND_THE_LAST_ONE: foo(); int y = baz(); I understand the desire to use "case X, Y:" instead, and I did consider it at length, but I found the lack of readability made it impossible. One trade off would have been: case SOME_BAD_THING, case SOME_OTHER_CONDITION, case HERE_IS_NUMBER_THREE, case AND_NUMBER_FOUR, case AND_NUMBER_FIVE, case AND_THE_LAST_ONE: foo(); int y = baz(); But it felt clearer to stick to C syntax, despite the inconsistency.
- fn-mote 1y ago> In C I regularly end up with lists that have 10+ fallthroughs like this [...] Frankly, that seems like a code smell, not a problem that needs a solution within the language.
- lerno 1y agoNo, it's not a problem. If you think it's a problem, write a C compiler in C and come back to me and show me your code that doesn't have that. :)
- sixthDot 1y agoMany languages propose a system of ranges: case 'a' .. 'z', 'A' .. 'Z', '0' .. '9', '_': ...; although when working with enumerators, there is a still a risk caused by the fact that re-ordering enumerators or adding new ones can break the switches. Despite of the drawback I prefer. Also a Range can be a formal expression which simplifies the grammar of other sub-expressions and statements, not only switches but also array slices, tuple slices, foreach, literal bitsets, etc.