On Sun, Nov 22, 2020 at 11:54 PM Finn Thain fthain@telegraphics.com.au wrote:
We should also take into account optimisim about future improvements in tooling.
Not sure what you mean here. There is no reliable way to guess what the intention was with a missing fallthrough, even if you parsed whitespace and indentation.
It is if you want to spin it that way.
How is that a "spin"? It is a fact that we won't get *implicit* fallthrough mistakes anymore (in particular if we make it a hard error).
But what we inevitably get is changes like this:
case 3: this();
break;case 4: hmmm();
Why? Mainly to silence the compiler. Also because the patch author argued successfully that they had found a theoretical bug, often in mature code.
If someone changes control flow, that is on them. Every kernel developer knows what `break` does.
But is anyone keeping score of the regressions? If unreported bugs count, what about unreported regressions?
Introducing `fallthrough` does not change semantics. If you are really keen, you can always compare the objects because the generated code shouldn't change.
Cheers, Miguel