4 ms·

Nowadays GCC warns about implicit fall-through. If you want to have a fall-through, you have to annotate it with, e.g /* fall-through */ This is of course not

Nowadays GCC warns about implicit fall-through. If you want to have a fall-through, you have to annotate it with, e.g /* fall-through */ This is of course not ideal, suddenly comments have to be considered by the compiler. But I guess it's the only way to fix this in a backwards compatible way.

melling 7y ago
Shouldn’t we optimize for the common case? The language should do want we want most of the time.
- toast0 7y ago
  We should not optimize for the common case at the expense of making the uncommon case impossible. With C style switch, you can fall through or break. In languages that don't provide fall through (say Erlang's case expression), if you have something that fits fall through, you need to either duplicate the inner code, or have a more verbose construction with multiple phases of matching.
  - melling 7y ago
    So, 99% of the time to need to be more verbose to handle the 1% case? I’d rather wrap the duplicate code in a function and call it in each instance.
- jnordwick 7y ago
  You're thinking about C's switch statement the wrong way. You are thinking about where a value is used to determine which block of code to run, like a ramped up conditional or an if-else-if chain. C's switch is a more a complex goto statement. All the case statements are labels and the switch does a goto label for the correct value. Those labels just need to be inside the switch block. This is why you can switch into the the middle of a looping construct or if-statement. In this way, break is kind of the oddity and sugar for goto past end of the switch block. This allows for some complex control flow that is kind of useful in a language without much else to offer in that regard (besides the ugly setjump hackiness).
WhiteSage 7y ago
C++17 includes the [[fallthrough]] attribute built into the language to disable the warning [1]. [1] https://en.cppreference.com/w/cpp/language/attributes/fallthrough https://en.cppreference.com/w/cpp/language/attributes/fallth...

melling 7y ago

Shouldn’t we optimize for the common case? The language should do want we want most of the time.

toast0 7y ago
We should not optimize for the common case at the expense of making the uncommon case impossible. With C style switch, you can fall through or break. In languages that don't provide fall through (say Erlang's case expression), if you have something that fits fall through, you need to either duplicate the inner code, or have a more verbose construction with multiple phases of matching.
- melling 7y ago
  So, 99% of the time to need to be more verbose to handle the 1% case? I’d rather wrap the duplicate code in a function and call it in each instance.
jnordwick 7y ago
You're thinking about C's switch statement the wrong way. You are thinking about where a value is used to determine which block of code to run, like a ramped up conditional or an if-else-if chain. C's switch is a more a complex goto statement. All the case statements are labels and the switch does a goto label for the correct value. Those labels just need to be inside the switch block. This is why you can switch into the the middle of a looping construct or if-statement. In this way, break is kind of the oddity and sugar for goto past end of the switch block. This allows for some complex control flow that is kind of useful in a language without much else to offer in that regard (besides the ugly setjump hackiness).

WhiteSage 7y ago

C++17 includes the [[fallthrough]] attribute built into the language to disable the warning [1]. [1] https://en.cppreference.com/w/cpp/language/attributes/fallthrough https://en.cppreference.com/w/cpp/language/attributes/fallth...