Extending and Simplifying C++: Thoughts on Pattern Matching using `is` and `as` - Herb Sutter

---
C++20 is a unique historic milestone: It's the first edition of Standard C++ that’s “D&E-complete,” with essentially all of the features Bjarne Stroustrup outlined in /The Design and Evolution of C++/ for C++’s evolution. That doesn’t mean evolution is done, however, and work continues on adding a few more important features in C++23 and beyond, including reflection and pattern matching.

In this talk, I’ll show the C++ pattern matching libraries and language proposals we’ve considered, and present my own contribution that builds on them. My paper has two major aims: (1) to make the syntax clean and regular, and avoid inventing a little sublanguage that works only inside “inspect”; and (2) to make it generalizable so we can use it consistently throughout the language, because matching a pattern is a broadly useful feature that ideally should not be limited to “inspect” only… for example, we would love to express patterns in “if” and “requires” conditions too.

I hope that the most important contribution is that, if we add pattern matching in a way that also provides general “match” and “extract” support throughout the language in the form of generalized “is” constraints and “as” casts, the net result is that we can actually simplify C++… yes, even as we add new features and more expressive power. How can that be simpler? By letting programmers directly express their intent where they have to express it indirectly today, by making the language more regular with fewer special cases to learn, by unifying the syntax of existing standard library features that today have a gaggle of different and divergent styles (e.g., variant, optional), and by providing one general and expressive way to use patterns cleanly throughout C++.

---
Herb Sutter
Software architect, Microsoft
Herb is an author, designer of several Standard C++ features, and chair of the ISO C++ committee and the Standard C++ Foundation. His current interest is simplifying C++.

---

[Versachiful]

I love Herb's talks. He always makes me see C++ from a new perspective :)

[bishophome]

Alexandresku had great insights, love how he sees things through

[PikachuSlapping]

Love this talk! Stuff like this makes me so excited for the future of the language. I understand it may have taken us a while to get here, but I'm glad we've reached it!

[davidkennedydev]

To the other ones watching this meeting: don't lose the last minutes.
It's an excellent wisdom sample.

[numv]

Wise words from Bjarne at the very end

[aliancemd]

I don't get why we are pretending and have to always use a different name, just name it "match" - it would be easier to jump between the codebases and it's more accurate to what is actually happening "pattern matching".

[saulth]

Yay for not having to write auto everywhere like the if-else block example. Keep up the good work improving C++ 😎

[MindGameArcade]

Great, great talk, so good to see all the community coming together, godbolt, Sean Baxter, llvm, etc.

[theRECONN]

Haha, "C-style cast is a Mystery cast". I am gonna call it that way from now on.

Interesting talk from Herb, as always.

[bioweapon]

Like the proposal, except for "inspect". Sticking to "switch" is not bad: the "=>" can mean ":" + break. And if we really need a new keyword, why not "match"? Python and Rust already have that, so it's becoming popular.

[cppmsg]

I would prefer switch to get more capacity rather than creating a new verb "inspect", the word I find inconsistent and confusing. The word seems so passive, and the function does what switch/case does, do we need yet another keyword that does something similar to another. The fact that I would have to look for => is not a problem for me. I enjoyed the whole talk and thanks to Herb. :)

[gongfei]

I love listening to Herb's talk !

[sanjaygatne]

nice talk. amazing work done by sean baxter.

[oisyn-]

Great talk. The syntax is a bit confusing though. Why "x is int", but if you want a named binding, you do "auto y is int = x"?
"x is int y" would make more sense to me. After all, you're testing whether 'x' is int, not 'y'. Not sure what the parseability of that is though, but the proposed syntax seems very backwards and inconsistent.

[Omnifarious]

I agree with Jason. `as` will frequently be used in contexts where the source type is unknown because it's a template.

[martinmckee]

One of the features I really loved when I learned Erlang was the pattern matching. Having some version of this in the language would be great.

[fdwr]

18:03 That's beautiful, simplifying multiple disparate ways of doing it with a consistent is and as.

22:14 "auto i is int = x" Having a hard time mentally parsing this. 🤨

I get this: (i is int)
Or this: (auto i = x)

But there's no placement of parentheses that makes this make sense 🙃:

"(auto i is int) = x" What? bool = x?
"auto (i is int) = x" Nope. auto bool = x?
"auto i is (int = x)" Huh?

We already have the existing "if (auto a = b; condition)". So let's find a way to be self-consistent within the language, more like "if (auto i = x; x is int) " (though, the problem here is the initialization order happens before the test :/).

27:00 Please no. "auto [_, y] is [0, even]."

32:08 Why doesn't variant have an intuitive straight-forward is_type() method? v.is_type() would be much clearer and more discoverable than the mouthful std::holds_alternative(). Bjarne speaking of uniformity at the end really highlights variant as the oddity in the bunch compared to optional and any. I mean, why do optional and any have has_value, but variant has this awkward interaction with monostate?

35:21 The UFCS nay-sayers stand on flimsy arguments. I so wanted this yesterday, as did Bjarne.

41:31 "inspect" feels like a really awkward verb. Inspect doesn't imply matching or branching. "match" or "branch" implying matching and branching. So just call it "match". The feature's name is after all "pattern matching".

41:56 Using "=>" for this purpose, how does that play into future terse delegates? Will they cooperate nicely and both be parseable?

45:26 Interesting that this obviates the immediately invoked function expression using lambdas to achieve switching.

55:11 Gah, what? These "refinements" don't appear to be simplifying the language, unlike "is" and "as" which do simplify it 😯.

1:00:17 "They are saying C++ is too complex" Yeah, so let's be careful about what we add, lest we make it considerably more complex to understand, more 18:03 and less 55:11.

1:08:01 Speaking of cleaning up divergent syntax where we can, tuples of varying types (e.g. parameter lists in function calls) have historically been grouped together via parentheses (or angle brackets in the case of std::tuple), not square braces, which are used for arrays. So abusing [] for lambdas (C++11 mistake) and now structured bindings and now apparently pattern *match*ing is definite room for language cleanup. Alas, it's probably the operator comma inside parentheses that complicated all this.

1:12:45 When both the creator of C++ and ISO C++ committee chair want UFCS and it still hasn't happened, then it's clearly a challenge to get through.

1:26:45 I'm also quite happy with the explicitness of an "as" being clear enough to the compiler that I mean the cast that I mean. The warnings about double to float are just obnoxious.

Ok, I'm glad this isn't arriving in C++23, because it still feels half baked, with part beautiful and part hideous, and I'm hoping that by C++26 it will more elegant and self-consistent.

[kg]

My take would be: either adding the functionality to `switch` or maybe use `match`, actually it makes more meaning to me, plus I think it resonates the idea of pattern matching to many having even wrote a hello world in Rust, and i think there are a lot in C++ community also :D

Since "if" is already a pattern, can we have "else" instead of "is _"? Thanks.

[VioletGiraffe]

I can't believe no one let Bjarne take their spot higher up the line when asking the questions...