From: Jason McKesson <jmckesson_at_[hidden]>
Date: Sun, 25 May 2025 11:34:35 -0400
> 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.

Some argue that fallthrough is a pitfall, while others disagree¡ªat the very least, I consider it a feature. Since it has its rationale for existing, why should it be deemed a mistake?

> 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.
If we already have 'switch', why do we need another 'match' with identical functionality? As someone with decision fatigue and OCD tendencies, should I keep using switch in my existing code or migrate everything to match?

> 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.

My position in this very thread has been entirely consistent. For such a distinctive feature, I wouldn't make the same mistake twice. You don't often make such mistakes, do you?
> 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.
So should we define a dedicated destructor class in every single function? Admittedly, I typically use 'goto __finally__;' as a substitute for finally blocks (which is quite common practice), as it makes my code cleaner. Or perhaps, like Golang, we could introduce a keyword like "defer" to serve as an anonymous destructor class - though neither finally nor defer actually exist in C++.
> And, again, pattern matching does not exist to get rid of fallthrough; it just happens to do that by being better than 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.
Pattern matching isn't a first-class feature in my development workflow either. laughing...
> 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.
What about pointers to classes derived from parent classes?
class base;
class derived : public base;
base* pBase= new derived();

pBase match {
<base*> => printf("base");
<derived*>=>printf("derived");
}
Which branch will be executed?
Pattern matching without regex support, lacking type operators, ambiguous derived class pointers, and ultimately no clear milestone planning, is it really the future?