Date: Sun, 25 May 2025 11:34:35 -0400
On Sun, May 25, 2025 at 7:10 AM Zhao YunShan via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> The bugs caused by fallthrough are typically mistakes made only by beginners. Fallthrough is not such a significant shortcoming that requires replacing with a new keyword.
Pattern matching does not exist to deal with fallthrough bugs. It has
its own, very valid, reasons for existing. But since the pitfalls of
fallthrough are quite obvious, pattern matching doesn't have it.
But even that's not the reason why pattern matching replaces switch.
It replaces switch because... it's doing the same thing. Switch takes
an integer, compares it to other static integers, and decides what to
do based on those comparisons. That's pattern matching; it's extremely
limited pattern matching, but that's what it is. There's no way to
design pattern matching functionality in a way that's still genuinely
pattern matching without also subsuming switch.
You can try to rename what switch is doing by calling it a "jump
table" or "multi-way branch". But the obvious fact remains: the two
pieces of functionality are, at a semantic level, doing the same
thing: selecting which code to execute based on an input value and a
bunch of things to compare it to.
As for only beginners making mistakes with fallthrough... citation
needed. In this very thread, *you* made a mistake with fallthrough
behavior (or at the very least, you put it on other maintainers to not
turn your mistake into a bug). You didn't even use the
`[[fallthrough]]` attribute that would have allowed the compiler to
detect when you intended fallthrough behavior and when you didn't.
> If every defect in C++ keywords (like switch) were to be addressed by redefining new keywords, wouldn’t the number of keywords in C++ grow endlessly over time?
>
> For example, since C++'s try...catch... construct lacks a finally block, does this mean we need to introduce a new set of keywords.
No, because C++ has destructors and RAII. Basically, anything you
could put into a finally block could better be put into an object's
destructor. Finally-based cleanup is for resources that cannot be
cleaned up by stack unwinding. Which is generally undesirable in C++
anyway.
And, again, pattern matching does not exist to get rid of fallthrough;
it just happens to do that by being better than switch.
>From your other post:
> First, there is no regex (regular expression) matching, as match is a supperset of switch.
Regex is certainly something pattern matching *can* do. But that would
be because the things you're comparing the strings to would be regular
expression objects of some kind that engage with pattern matching.
Regular expression text will never be a first-class feature of the C++ language.
> How to Handle Multiple Type Operators When Matching Variants?
That's not a variant; that's a type with some conversion operators.
At the moment, the variant matching behavior of pattern matching only
appears to work with `std::variant`. The intent is to later expand
this to user-created types with variant-like behavior.
<std-proposals_at_[hidden]> wrote:
>
> The bugs caused by fallthrough are typically mistakes made only by beginners. Fallthrough is not such a significant shortcoming that requires replacing with a new keyword.
Pattern matching does not exist to deal with fallthrough bugs. It has
its own, very valid, reasons for existing. But since the pitfalls of
fallthrough are quite obvious, pattern matching doesn't have it.
But even that's not the reason why pattern matching replaces switch.
It replaces switch because... it's doing the same thing. Switch takes
an integer, compares it to other static integers, and decides what to
do based on those comparisons. That's pattern matching; it's extremely
limited pattern matching, but that's what it is. There's no way to
design pattern matching functionality in a way that's still genuinely
pattern matching without also subsuming switch.
You can try to rename what switch is doing by calling it a "jump
table" or "multi-way branch". But the obvious fact remains: the two
pieces of functionality are, at a semantic level, doing the same
thing: selecting which code to execute based on an input value and a
bunch of things to compare it to.
As for only beginners making mistakes with fallthrough... citation
needed. In this very thread, *you* made a mistake with fallthrough
behavior (or at the very least, you put it on other maintainers to not
turn your mistake into a bug). You didn't even use the
`[[fallthrough]]` attribute that would have allowed the compiler to
detect when you intended fallthrough behavior and when you didn't.
> If every defect in C++ keywords (like switch) were to be addressed by redefining new keywords, wouldn’t the number of keywords in C++ grow endlessly over time?
>
> For example, since C++'s try...catch... construct lacks a finally block, does this mean we need to introduce a new set of keywords.
No, because C++ has destructors and RAII. Basically, anything you
could put into a finally block could better be put into an object's
destructor. Finally-based cleanup is for resources that cannot be
cleaned up by stack unwinding. Which is generally undesirable in C++
anyway.
And, again, pattern matching does not exist to get rid of fallthrough;
it just happens to do that by being better than switch.
>From your other post:
> First, there is no regex (regular expression) matching, as match is a supperset of switch.
Regex is certainly something pattern matching *can* do. But that would
be because the things you're comparing the strings to would be regular
expression objects of some kind that engage with pattern matching.
Regular expression text will never be a first-class feature of the C++ language.
> How to Handle Multiple Type Operators When Matching Variants?
That's not a variant; that's a type with some conversion operators.
At the moment, the variant matching behavior of pattern matching only
appears to work with `std::variant`. The intent is to later expand
this to user-created types with variant-like behavior.
Received on 2025-05-25 15:34:48