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!
We haven't reached it yet... None of these are expected to ship in c++23, and all of these were talked about 5 years ago already. C++ evolves slowly by design. It's not python. I expect to see some of Sutter's proposals make it to c++29.
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.
Popular languages that have a "match" keyword use it as expressions, whereas "inspect" is a statement. The motivation behind this name difference is to reduce confusion between languages.
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. :)
Maybe "given" instead of inspect, or "evaluate" or "pachinko" ;) I'd maybe agree on the second point except a) ambiguity kills new users, switch needs to mean one thing and b) the committee have C switch compatibility to consider.
I think that overloading the same words over and over and over again can make the language more confusing for users. And there is still the point about C compatibility so I feel that the new keyword is justified.
Also, I've never liked the word switch in programming in general, so I'm realizing I'm biased here. Like `which` or `select` makes sense. I just memorized that switch is what is used there.
@@KhalilEstell Switch works for me because you think of it like a train track switch, which only follows one track. "inspect" though makes near zero sense as a verb, and @dmacmakes choice of "given" or "evaluate" make more sense. Though "match" is still my favorite given it is pattern *match*ing.
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".
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.
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.
@@jhbonarius Yes. Herb is also working for MS, I don't think he doesn't know how C# does it. Why he chose this syntax? Or it came from other collaborators?
@@7mile929 Yes, I believe he is using the same syntax from C# to not reinvent the wheel when you don't have to. But yeah it does look strange to me. I don't really have too many complaints otherwise though.
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
Yeah, "inspect" as a verb makes little sense and sounds quite awkward. Inspect doesn't imply matching or branching. "match" or "branch" implying matching and branching. So just call it "match" - the feature's name is "pattern matching" after all.
I personally believe inspect makes more sense than match, because you're inspecting an element for the most part. In Rust, you can quite literally match with monadic types like Result and Option. In C++, we don't have Some() and None, or Ok() and Err(). I still prefer try except blocks for errors, because it looks a bit clearer for that specific purpose, but for std::optional we really need to have an easier way to do pattern matching, although I'm happy with .value_or(). Pattern matching is becoming fairly decent in C++ as time goes by. It really fuels more and more passion for the language into me.
There's going to be many, many Stack Overflow questions in the future. Having powerful simplifications going forward will help people who make professional C++ code, but students will always investigate all there is out there. One of the most common question types about C++ on Stack Overflow is either directly about or silently contains something like a C-style array instead of an std::vector, std::array, or std::string. The older material will stay forever. Plus, while powerful abstractions help people comfortable with C++, they are often a source of confusion for new programmers who are trying to memorize the 8 different meanings of is or as shown in a table inside some book.
That's where Bjarne's "A Tour of C++" book comes in, I think. The old material will stay forever, but now that we have a relatively succinct guide on how to write modern code we might as well forget about that old stuff.
That is the reason why I never write C++. If I need classes, I emulate them on C with structures. It works extremely well without having to resort to the ridiculous syntax of C++. And yes, I used to do C++ all the time. I spent 90% of my time trying to figure out obscure compiler errors. It's a language that gets in the way every time it tries to "help". Only thing worse are VHDL and Verilog.
C++98: C-style cast may have multiple different meanings so we added *_cast syntax to make programmers' intentions explicit. C++23: We reinvented C-style cast, but now you can even get value from optional or future with exactly the same syntax as type casting.
When I learned about Rust’s “as” keyword, it just made so much sense. In my mind, that idea kinda defeats the need for weak_ordering. No need to weak_equality filepaths - just equality them as strings or equality them as file locations. If you need to make the distinction between the two valid equalities on these types then you should always unambiguously declare which one you wish to use - failure to do so should be a compiler error. I do believe that leaning hard on the type system creates better code. That is thought but not impossible to do in C++. Anything that makes that easier, ANYthing,,, I think that’s a win. There is so so much potential, and my gosh it really is a different language now than it used to be. That spooks and excited me.
One more highlight of the talk for me was 1:11:35 when he said that about the spaceship operator. It’s makes perfect sense that we don’t need to give code that returns any more than “more than”, “equal”, or “less than”! That it makes the standard smaller too... It IS that simple!
One thing unclear to me is the order of operations? If you say "animal as Mammal.Mouth", does that mean "(animal as Mammal).Mouth" or "animal as (Mammal.Mouth)", where the first casts to mammal and reads a Mouth property and the second casts Animal to a Mouth type.
Talking from the C# community: yes many people love pattern matching, but just as many hate it. In my company for instance it's not allowed to use it, as the lead engineers want to keep the coding style uniform. New features often seem to lead to a spilt in the community: conservatives vs progressives.
It just takes time to adopt new language features. And sometimes adding them to a large code base makes it less readable (unless you refactor all of it), so better add it to new projects.
Yep, that's why I'm contemplating switching jobs from developer to researcher. I am so done discussing code standards and naming conventions and which feature we shouldn't use because opinions and why named lambdas should never be used, not even single line ones, because opinions. Seriously fuck this shit.
last 2 decades C++ was trying to stabilized and establish itself as the most important language on the planet to design and maintain mission critical evolving system. I think next decades will be very interesting and some original C++ features will be out soon
I would also have loved it... But unfortunately, it's not planned to be included. At the pace c++ is evolving, maybe we'll see it in c++29, but don't hold your breath. Anyway, it's good to have something to look forward to. Maybe c++ should have a lts/stable branch and an experimental/dev branch? I guess Godbolt is kinda that, maybe we should make it work offline too.
I would like half of it to be accepted, the clean half which reduces complexity and increases language consistency ("as" and "is"). The other, the pattern matching (which I'll call "match" because "inspect" is an awkward and unintuitive verb for this usage) needs more bake time. So I'm kinda glad this isn't in C++23, as 26 will give it more time to iron out the kinks.
@HerbSutter There is something left implicit, inspect will evaluate is/as in the order they are written in. Specialy clear in cases with "is _" you don't want to have that on top. Just a bit of nitpicking on syntax here, I'd rather type "default (or else)" then "is _" (default/else is intent, is "_ is" the how/implementation detail)
Switch started as assembler pattern, fallthrough semantics is an advantage, the only improvement should be done by breaking by default and falling using *continue* keyword.
@@not_ever He didn't say to change the behaviour of switch now - that would have been needed to be done waaay back in time. But for pattern-matching NOW this would be important.
Don't ever stop wearing aloha-shirts. I'm really excited about the is/as concept thingies. Although as some have pointed out (auto i is int = x) is very hard to parse as a human. It doesn't seem to rhyme with the rest of the language. As with everything in programming. Nothing magically becomes better and nothing is for free. Everything has a cost, just like the law of conservation of energy.
Though I agree with the 2nd last person, I think it's adding more and more things for complexity, it kind of becoming like some ancient programs (I dont know of other language's progresses), with a baggage of the past
pretty sure he said "gestalt and weltschmerz" which are both very real German words. "gestalt" -> shape, form, character "weltschmerz" -> a sense of depression arising from the comparison of the true state of things with the ideal state of things.
Be careful not to over-confuse the language, folks - and that's the way it's heading. Your desire to 'protect' the existing codebase is tying you back - compilers can be modified! There's absolutely nothing wrong with extending (not changing!) the functionality and/or intent of an existing statement...better for everyone(!) to have 'everything under the one roof'.
How can i use later versions of C++ where older versions are mentioned/recommended, e.g. VS-C++ for UNREAL ENGINE is version 14 if I am not mistaken. More generally, does a newer version compiler have an inbuilt 'version switch' or is there an unbuilt 'backward-compatibility' as WELCOME news.
It's a pity that in the embedded world with no-rtti and C HALs that we are still stuck being forced to use reinterpret_cast for uint8_t buffers to/from hardware and cannot use std::variant so have to fall back to unions. I can't wait for the day when we have C++ HALs, but I genuinely don't see that happening any time soon if ever. So we are stuck with these "unsafe" and "discouraged" constructs. For me as an mid career embedded firmware engineer trying to stay up to date with best practices, then going to work and having to do something contrary, it is really demoralising.
You can use variant and optional without RTTI or exceptions. I use both in some STM32 projects. Now don't get me started on no reinterpret cast (c style memory mapped register casts) in constexpr land.
I think he was trying to avoid an exception in the case that x couldn't be accommodated, such as with an empty optional where "as" would either explode or be undefined behavior if not tested first.
I have the same question, I guess it did so to make it more comparable with the non patter matching syntax. Also the actual syntax would be: if (auto x as int = v) {}
Nice job Herb! and I don't like break;case.... but meh. switch(v) { case 1: fn(); break; case 2: // fall through case 3: gn(); } vs switch(v) { break case 1: fn(); break case 2: case 3: gn(); } I find the first easier to read.
Every year I'm asking about introducing namespaces for keywords, but nobody seems to be interested. Instead we ended up with ugly keywords like co_xxx, and inevitably there will be more of those as conflicts with the existing user codebase arise.
Interesting - never thought of that before. You could imagine a std23 namespace with the await keyword, and to consume it, just say "using std23". 🤔 I like it.
Some people would learn just the high level stuff without any understanding of the basis. I've already seen people misusing auto leading to extremely expensive to fix bugs. They don't know what type there should be, so they just stick auto in there and if it compiles, they consider their work complete. Python exceptionally more notorious than C++ with this type of problems that the high level languages have. Haskell in than sense is much safer and the compiler punishes those unqualified people to the extent of them giving up on programming. I would personally like to have more control over side effects and code misuse in C++. I would also like the template and type-level code being more concise. Some user defined sugar would be nice. There are places where templates are the answer and the types need to be derived by the compiler using few very simple rules. The type-level assignments(template using ...) are fine, but the branching(typename std::conditional::type) is horrible to read and write. Nevertheless I am glad those features are present, because just yesterday I've wrote 30 horrible lines of code and then just copy-pasted/transformed few thousands from the spec to get the job done. It took me hours instead of weeks. The type-level code in C++ is kinda hard to work with though. I like Haskell and ghc compiler because the TemplateHaskell extension allows to run arbitrary code at compile time and in the modern world there are many cases where that would be incredibly useful. That's what generic programming should be - arbitrary code to generate C++ code, not just some templates, constexprs, defines and the auto keyword. P.S. Only on the Haskell job from my past we didn't have our own unique in-house developed code generating tool.
"is-as" are another overhead for the compiler. Even though, inspect syntax looks good, RBT rotate example is horrendous. Well, I don't want to see my beloved language turn into some scripting language because someone finds it "complex" or "unsafe". These "complex" and "unsafe" features makes c++ program is performant and separate professional and a rookie. The committee should consider these proposals to "make C++ less complex".
But c++ operates under the zero overhead abstraction principle. So whilst it might cause more overhead for the compiler at compile time, it should result in exactly the same runtime result whilst producing more expressive readable code, which is arguably what actually matters.
They're both becoming more like F#. The C# team especially has been playing catch-up to F# for years, according to Don Syme himself. C++ is still king for performance, and obviously for manual memory management, but in every other way, F# destroys it. Soooo much better.
There are many projects that don't want to pay the cost of RTTI. I have literally never worked in a code base that had RTTI on. If RTTI is off, what does "x is Derived" and "x as Derived" going to do? Compile time error? Will turning off RTTI force people into using the old syntax? My favorite part of this talk was the switch details. I always suspected/hoped that is how switches were optimized and have always worried that I should be rolling my own jump tables to be sure that is what I was getting (casually inspecting the assembly generated for a function in a large project tends to discourage confirming things at times). What I want is a special switch keyword that will only ever result in a jump table and give me a warning/error if it cannot produce a jump table for my switch statement. A large switch in a tight loop could be branch prediction hell or it could be lightning fast if it is in a jump table, and I'd like to be able to express my intent at more than just the semantic level, I want to express my intent at the algorithmic level that impacts the hardware.
We have effective UFCS: `auto foo_call(auto x) { if constexpr (require { x.foo() }) { return x.foo(); } else { return foo(x); } }`, it verbose and require helper function for each function you want use.
Herb trying to do good, I can't see why C++ committee so adamant about having ugly syntax like std::holds_alternative (which is not clear at all btw) over simpler syntax
Features, features, more features. This is great, but the hard part is getting this to work with all the other language features. Don't we have like a 100 things that this needs to work with, like constexpr volatile coroutine-generated objects on the right hand side of the "is" expression, just to give a dumb example? Seriously, just name some random combination of features that can affect types and see if this works with them correctly (also without accidentally adding potential for writing buggy code). Just using the new feature as intended is not enough of a test in a language as complex as C++.
The committee see to become more and more the ivory-tower that must be avoided. The fallthrough-behaviour is one of the most important features of the switch-statement. It allows us to write more concise code and reduce code-duplication and mental gymnastic. But it is same as with many of the older constructs that some of their behaviour just make them harder to use then they should be. Instead of not including one of the most useful features (that then would be grandfathered in with much pain a couple versions later) it would be way simpler to have the behaviour in a configurable way. As an example - why not a specifier after the expression? "explicit fallthrough" - would make it clear that only by explicitly writing a fallthrough-keyword (or attribute or whatnot) would a pattern exhibit fallthrough behaviour. and "default fallthrough" would do the opposite. having a new keyword ... not sure if that is really helpful. Yes - "having to scan through" makes it sound bad, but that is not really the case. It would STILL be a switch-statement but with some other restrictions and liberties, but fundamentally it IS a "switch". Heck, by sticking with "switch" and ":" one could easily enhance switch by ADDING "=>" to the syntax and making it denote a none-fallthrough case. std:.string name = /*...*/; switch(name){ case "Dave": case "David": case "Davie" => std::cout std::cout
For the explicit fall through continue would be a good fit as it is the "opposite" of break and isn't used so far in switch and it also avoids introducing yet another new keyword
@@pizzawithpineappleissuperi4377 but the switch may be inside a loop so continue already has meaning. In D we use `goto case` (with an optional expression) or `goto default`.
inspect keyword: Exists. c#: Oh, come on! c++ user: I have to pay only what I only use even if it's compile time cpu-cycle overhead. 🤷🏻 Please please consider fixing this. I just don't see any down sides with the polymorphic switch keyword.
This proposal is so bad. Generic programing is not about knowing type. It is about not knowing it. We do thinks for base class and we should not know what child is this class. If we need know if this is int or float we now have if constexpr and it works. If you want sever switch then simply propose that [[fallthrough]] is always needed when you want it.
In every language community everyone is always referring to how F# does it right and they should strive to be more like it! I guess that is why it is the most popular and widespread language in existence, especially for systems programming
C++ becomes the ugliest programming language ever. Linus Torvalds was right when he said that "nothing is better than C". If you want to be more productive, learn Rust. RIP C++ :(
Instead of "inspect," consider calling it "select." That would be more intuitive/consistent with other languages. The syntax is also super wonky. I understand why you did it but think you are mistaken. You are throwing SYNTACTIC LOGIC out the window, making everything just gobbledygook. There's no syntactic intuition left. For example, `if(auto i is int = x)` is clearly there to prevent having to do `if(x is int) { auto i = x; ...}` and similar for the others. THIS IS BEING TOO CLEVER. We have been warned so many times not to be too clever. It makes code ugly and exactly why people don't want to learn C++. Little mental models of syntax that are logical/intuitive are the best asset to making a language teachable, learnable, and desirable. And we are failing this because somehow we think shaving a line or two (or a subline) is worth it? I'd rather take the slightly less compact code for SANITY any day. Reconsider! Just trying to parse the chain of values/types is so painful. And it is corrupting C++ away from the beauty of the logic of syntax of C's best bits. Without good reason. Even in the more complex cases like structured binding, I'd just rather have `inspect(x is [int, int, bool]){ auto [a, b, flag] = x; ... }` than `inspect(auto [a, b. flag] is [int, int, bool] = x)`. It's much clearer, and I gain almost nothing by going with CRAZY CODE. I wonder whether this is what Andrei meant about "lighter weight syntax." It seems like you're trying to do too much and f'ing up the syntactical logic in the process, making C++ EVEN weirder. For inspect, the more sane "lighter-weight" syntax would look like this: `inspect(x) { ` ` is int => {/* stuff */} ` ` is integral => {/* stuff */} ` ` is [int, int] => {auto [a, b] = x; /* stuff */} ` ` is [int, int, int] => {auto [a, b, c] = x; /* stuff */} ` ` is [0, even] => { auto [_, y] = x; /* stuff */} ` ` is string => { auto s = x as string; /* stuff */} ` ` default => {/* stuff */} ` ` } Of course, I would suggest changing it to `select(x)` instead of `inspect(x)`. But the point is, please don't try to smoosh things together into a bizarre, unintuitive syntax! SIDE NOTE about structured binding syntax: it would be nice if we could do [ , y] = x; where leaving an element in a structured binding empty ignores it. This would avoid silly tricks like discarding variable names and using _ and ___ and ____, etc. in structured bindings in general throughout the language, which is U.B. You use `_` in two very different ways here which is very problematic: both as a discard-variable name in a structured binding, and as a "type wildcard" for "none of the above TYPES." That seems prone to issues. So here I used `'default` instead for the latter. No `is` statement needed or warranted here IMO. However, I do want to be able to do stuff like: `inspect(x){ ` ` is [ , , bool] => {/* stuff */} // x is a 3-tuple of any types up to the last one, which is bool ` ` is [ , , , ..., float] => {/* stuff */} // x is a n-tuple of any types up to the last one, which is float ` ` is int; is bool => {/* stuff */} // x is an int or x is a bool ` ` is integral && std::less => {/* stuff */} // x is of an integral type and less than 100 ` `} ` As for the point about lossy is/as, consider `~is` and `~as`. ~ would mean "equivalent, potentially modulus any narrowing/lossy conversions including implicit ones." You could even have +as and +is to mean "exactly matches." (No conversions at all--even if provided.) Then `as` and `is` by themselves would mean the happy middle ground: "no implicit, compiler-provided narrowing or lossy conversions, but other user-provided conversions allowed." @37:42 I don't understand the variant code at all. I would have thought it should be like `template constexpr auto operator is( std::variant const& x) { return x.holds_variant(x); }` and `template constexpr auto operator as( std::variant const& x) -> auto&& { return std:::get(x); }` Instead, you ignore the types asked for and the corresponding type versions of std::variant methods, and work with indices??? All I can think is that you've added some magic to convert types to indices behind the scenes for variant-like types? What gives?
![เปิดบ้าน โคตรสวย ป๋องกพล รู้จักตั้งนาน เพิ่งรู้ว่ารวย!!! l [Nickynachat]](http://i.ytimg.com/vi/tmgCF_2HfYI/mqdefault.jpg)
I love Herb's talks. He always makes me see C++ from a new perspective :)
Wise words from Bjarne at the very end
Alexandresku had great insights, love how he sees things through
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!
We haven't reached it yet... None of these are expected to ship in c++23, and all of these were talked about 5 years ago already. C++ evolves slowly by design. It's not python. I expect to see some of Sutter's proposals make it to c++29.
To the other ones watching this meeting: don't lose the last minutes.
It's an excellent wisdom sample.
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.
Just call it "match"!
I use the name match for my variables frequently enough to be concerned about using it as a keyword. I have never used inspect for naming anything.
While I tend to agree, let's not get into bike shedding ;)
Popular languages that have a "match" keyword use it as expressions, whereas "inspect" is a statement. The motivation behind this name difference is to reduce confusion between languages.
Yay for not having to write auto everywhere like the if-else block example. Keep up the good work improving C++ 😎
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. :)
In a word the problem is compatibility. You can't really implement it well in a backward compatible way.
Maybe "given" instead of inspect, or "evaluate" or "pachinko" ;)
I'd maybe agree on the second point except a) ambiguity kills new users, switch needs to mean one thing and b) the committee have C switch compatibility to consider.
I think that overloading the same words over and over and over again can make the language more confusing for users. And there is still the point about C compatibility so I feel that the new keyword is justified.
Also, I've never liked the word switch in programming in general, so I'm realizing I'm biased here. Like `which` or `select` makes sense. I just memorized that switch is what is used there.
@@KhalilEstell Switch works for me because you think of it like a train track switch, which only follows one track. "inspect" though makes near zero sense as a verb, and @dmacmakes choice of "given" or "evaluate" make more sense. Though "match" is still my favorite given it is pattern *match*ing.
Haha, "C-style cast is a Mystery cast". I am gonna call it that way from now on.
Interesting talk from Herb, as always.
nice talk. amazing work done by sean baxter.
Much appreciated!
Great, great talk, so good to see all the community coming together, godbolt, Sean Baxter, llvm, etc.
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".
I love listening to Herb's talk !
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.
Agreed, inappropriate verb choice for "pattern *match*ing".
I agree with Jason. `as` will frequently be used in contexts where the source type is unknown because it's a template.
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.
That's the way C# does it
@@jhbonarius Yes. Herb is also working for MS, I don't think he doesn't know how C# does it. Why he chose this syntax? Or it came from other collaborators?
@@7mile929 Yes, I believe he is using the same syntax from C# to not reinvent the wheel when you don't have to. But yeah it does look strange to me. I don't really have too many complaints otherwise though.
I agree, I thought the same thing.
Yes I was stumped when i tried to parse that in english. Code should read like a prose and the proposed syntax doesn't
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
Yeah, "inspect" as a verb makes little sense and sounds quite awkward. Inspect doesn't imply matching or branching. "match" or "branch" implying matching and branching. So just call it "match" - the feature's name is "pattern matching" after all.
I personally believe inspect makes more sense than match, because you're inspecting an element for the most part. In Rust, you can quite literally match with monadic types like Result and Option. In C++, we don't have Some() and None, or Ok() and Err(). I still prefer try except blocks for errors, because it looks a bit clearer for that specific purpose, but for std::optional we really need to have an easier way to do pattern matching, although I'm happy with .value_or().
Pattern matching is becoming fairly decent in C++ as time goes by. It really fuels more and more passion for the language into me.
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.
There's going to be many, many Stack Overflow questions in the future. Having powerful simplifications going forward will help people who make professional C++ code, but students will always investigate all there is out there. One of the most common question types about C++ on Stack Overflow is either directly about or silently contains something like a C-style array instead of an std::vector, std::array, or std::string. The older material will stay forever. Plus, while powerful abstractions help people comfortable with C++, they are often a source of confusion for new programmers who are trying to memorize the 8 different meanings of is or as shown in a table inside some book.
That's where Bjarne's "A Tour of C++" book comes in, I think. The old material will stay forever, but now that we have a relatively succinct guide on how to write modern code we might as well forget about that old stuff.
That is the reason why I never write C++. If I need classes, I emulate them on C with structures. It works extremely well without having to resort to the ridiculous syntax of C++. And yes, I used to do C++ all the time. I spent 90% of my time trying to figure out obscure compiler errors. It's a language that gets in the way every time it tries to "help". Only thing worse are VHDL and Verilog.
C++98: C-style cast may have multiple different meanings so we added *_cast syntax to make programmers' intentions explicit.
C++23: We reinvented C-style cast, but now you can even get value from optional or future with exactly the same syntax as type casting.
When I learned about Rust’s “as” keyword, it just made so much sense. In my mind, that idea kinda defeats the need for weak_ordering.
No need to weak_equality filepaths - just equality them as strings or equality them as file locations. If you need to make the distinction between the two valid equalities on these types then you should always unambiguously declare which one you wish to use - failure to do so should be a compiler error.
I do believe that leaning hard on the type system creates better code. That is thought but not impossible to do in C++. Anything that makes that easier, ANYthing,,, I think that’s a win.
There is so so much potential, and my gosh it really is a different language now than it used to be. That spooks and excited me.
One more highlight of the talk for me was 1:11:35 when he said that about the spaceship operator. It’s makes perfect sense that we don’t need to give code that returns any more than “more than”, “equal”, or “less than”! That it makes the standard smaller too... It IS that simple!
Ben Deane is so cool. I have learned a lot from him and I am thankful. 1:16:00
And Jason Turner 1:25:53
One thing unclear to me is the order of operations? If you say "animal as Mammal.Mouth", does that mean "(animal as Mammal).Mouth" or "animal as (Mammal.Mouth)", where the first casts to mammal and reads a Mouth property and the second casts Animal to a Mouth type.
Talking from the C# community: yes many people love pattern matching, but just as many hate it. In my company for instance it's not allowed to use it, as the lead engineers want to keep the coding style uniform.
New features often seem to lead to a spilt in the community: conservatives vs progressives.
Fight the power!
It just takes time to adopt new language features. And sometimes adding them to a large code base makes it less readable (unless you refactor all of it), so better add it to new projects.
Yep, that's why I'm contemplating switching jobs from developer to researcher. I am so done discussing code standards and naming conventions and which feature we shouldn't use because opinions and why named lambdas should never be used, not even single line ones, because opinions. Seriously fuck this shit.
last 2 decades C++ was trying to stabilized and establish itself as the most important language on the planet to design and maintain mission critical evolving system. I think next decades will be very interesting and some original C++ features will be out soon
Since "if" is already a pattern, can we have "else" instead of "is _"? Thanks.
Agreed, akin to haskell's "otherwise". It makes sense to use a keyword for the backstop case
Yes, please no "_".
I can't believe no one let Bjarne take their spot higher up the line when asking the questions...
I really hope this gets accepted into C++23
I would also have loved it... But unfortunately, it's not planned to be included. At the pace c++ is evolving, maybe we'll see it in c++29, but don't hold your breath. Anyway, it's good to have something to look forward to.
Maybe c++ should have a lts/stable branch and an experimental/dev branch? I guess Godbolt is kinda that, maybe we should make it work offline too.
I would like half of it to be accepted, the clean half which reduces complexity and increases language consistency ("as" and "is"). The other, the pattern matching (which I'll call "match" because "inspect" is an awkward and unintuitive verb for this usage) needs more bake time. So I'm kinda glad this isn't in C++23, as 26 will give it more time to iron out the kinks.
Agree! That would make writing and reading C++ easier.
A side effet would be getting the joke: "C++ be like C#"
@HerbSutter There is something left implicit, inspect will evaluate is/as in the order they are written in. Specialy clear in cases with "is _" you don't want to have that on top. Just a bit of nitpicking on syntax here, I'd rather type "default (or else)" then "is _" (default/else is intent, is "_ is" the how/implementation detail)
Switch started as assembler pattern, fallthrough semantics is an advantage, the only improvement should be done by breaking by default and falling using *continue* keyword.
If you change switch to break by default you're going to be breaking a lot of existing code bases.
@@not_ever He didn't say to change the behaviour of switch now - that would have been needed to be done waaay back in time.
But for pattern-matching NOW this would be important.
One solution is to let the IDE auto complete the break for every case, unless you delete it to fall through.
Herb Sutter is a Canadian Nation Treasure.
Don't ever stop wearing aloha-shirts.
I'm really excited about the is/as concept thingies. Although as some have pointed out (auto i is int = x) is very hard to parse as a human. It doesn't seem to rhyme with the rest of the language.
As with everything in programming. Nothing magically becomes better and nothing is for free. Everything has a cost, just like the law of conservation of energy.
Though I agree with the 2nd last person, I think it's adding more and more things for complexity, it kind of becoming like some ancient programs (I dont know of other language's progresses), with a baggage of the past
1:10:39 Although this word doesn't actually exist, the pronunciation seems nearly perfect to me.
Yes it does indeed :D
pretty sure he said "gestalt and weltschmerz" which are both very real German words.
"gestalt" -> shape, form, character
"weltschmerz" -> a sense of depression arising from the comparison of the true state of things with the ideal state of things.
Be careful not to over-confuse the language, folks - and that's the way it's heading. Your desire to 'protect' the existing codebase is tying you back - compilers can be modified!
There's absolutely nothing wrong with extending (not changing!) the functionality and/or intent of an existing statement...better for everyone(!) to have 'everything under the one roof'.
Where is the talk by Sean Parent referred to by the commenter at the end?
Really should be match, but this is a wonderful addition, where is it?
.. This circle compiler is brilliant.
finally a same way to convert type to string
instead of guessing .str() .string() .to_tring()
Let's not forget easier ranges.
auto [_, _, c] is [auto &n *= 3]{3 : 9}; // 9, 12, 15, 18, 21, 24, 27 - so c is 15
Lovely idea! but destructing an array with more than 3 elements to 3 variables sounds like a bad idea.
How can i use later versions of C++ where older versions are mentioned/recommended, e.g. VS-C++ for UNREAL ENGINE is version 14 if I am not mistaken. More generally, does a newer version compiler have an inbuilt 'version switch' or is there an unbuilt 'backward-compatibility' as WELCOME news.
31:25 "requires requires" looks kind of goofy doesn't it?
It's a pity that in the embedded world with no-rtti and C HALs that we are still stuck being forced to use reinterpret_cast for uint8_t buffers to/from hardware and cannot use std::variant so have to fall back to unions. I can't wait for the day when we have C++ HALs, but I genuinely don't see that happening any time soon if ever. So we are stuck with these "unsafe" and "discouraged" constructs. For me as an mid career embedded firmware engineer trying to stay up to date with best practices, then going to work and having to do something contrary, it is really demoralising.
You can use variant and optional without RTTI or exceptions. I use both in some STM32 projects. Now don't get me started on no reinterpret cast (c style memory mapped register casts) in constexpr land.
It really motivates
what's the point of
if (v is int) {x = v as int
when you can just
if (v = x as int) {
or something like that
I think he was trying to avoid an exception in the case that x couldn't be accommodated, such as with an empty optional where "as" would either explode or be undefined behavior if not tested first.
I have the same question, I guess it did so to make it more comparable with the non patter matching syntax.
Also the actual syntax would be:
if (auto x as int = v) {}
Nice job Herb! and I don't like break;case.... but meh.
switch(v) {
case 1:
fn();
break;
case 2:
// fall through
case 3:
gn();
}
vs
switch(v) {
break case 1: fn();
break case 2:
case 3: gn();
}
I find the first easier to read.
Every year I'm asking about introducing namespaces for keywords, but nobody seems to be interested. Instead we ended up with ugly keywords like co_xxx, and inevitably there will be more of those as conflicts with the existing user codebase arise.
Interesting - never thought of that before. You could imagine a std23 namespace with the await keyword, and to consume it, just say "using std23". 🤔 I like it.
As good as always!
Glad you think so!
Hilarious Steve Jobs reference at 54:00
Sad that Circle C++ is closed source, would love to use it but that's a hard no.
Same here, that's unfortunate
Wow! This is amazing!
Thank you so much!
Wow, Herb. You didn’t address Bjarne’s concerns or postpone doing so
Some people would learn just the high level stuff without any understanding of the basis. I've already seen people misusing auto leading to extremely expensive to fix bugs. They don't know what type there should be, so they just stick auto in there and if it compiles, they consider their work complete. Python exceptionally more notorious than C++ with this type of problems that the high level languages have. Haskell in than sense is much safer and the compiler punishes those unqualified people to the extent of them giving up on programming. I would personally like to have more control over side effects and code misuse in C++. I would also like the template and type-level code being more concise. Some user defined sugar would be nice.
There are places where templates are the answer and the types need to be derived by the compiler using few very simple rules. The type-level assignments(template using ...) are fine, but the branching(typename std::conditional::type) is horrible to read and write. Nevertheless I am glad those features are present, because just yesterday I've wrote 30 horrible lines of code and then just copy-pasted/transformed few thousands from the spec to get the job done. It took me hours instead of weeks. The type-level code in C++ is kinda hard to work with though. I like Haskell and ghc compiler because the TemplateHaskell extension allows to run arbitrary code at compile time and in the modern world there are many cases where that would be incredibly useful. That's what generic programming should be - arbitrary code to generate C++ code, not just some templates, constexprs, defines and the auto keyword.
P.S. Only on the Haskell job from my past we didn't have our own unique in-house developed code generating tool.
"is-as" are another overhead for the compiler. Even though, inspect syntax looks good, RBT rotate example is horrendous. Well, I don't want to see my beloved language turn into some scripting language because someone finds it "complex" or "unsafe". These "complex" and "unsafe" features makes c++ program is performant and separate professional and a rookie. The committee should consider these proposals to "make C++ less complex".
But c++ operates under the zero overhead abstraction principle. So whilst it might cause more overhead for the compiler at compile time, it should result in exactly the same runtime result whilst producing more expressive readable code, which is arguably what actually matters.
As if C++ is becoming more C#-like, and C# is becoming more C++-like.
Mr. Sutter is from Microsoft.
C++ has had these ideas for a long though. C# moves faster. I'd say C# tries to emulate C++ not the other way around
They're both becoming more like F#. The C# team especially has been playing catch-up to F# for years, according to Don Syme himself.
C++ is still king for performance, and obviously for manual memory management, but in every other way, F# destroys it. Soooo much better.
Sutter's papers have a wild and very distinctive style of syntax but, now that I think of it, yes, the influence is evident. :)
"for cast we have many incantations"
There are many projects that don't want to pay the cost of RTTI. I have literally never worked in a code base that had RTTI on. If RTTI is off, what does "x is Derived" and "x as Derived" going to do? Compile time error? Will turning off RTTI force people into using the old syntax?
My favorite part of this talk was the switch details. I always suspected/hoped that is how switches were optimized and have always worried that I should be rolling my own jump tables to be sure that is what I was getting (casually inspecting the assembly generated for a function in a large project tends to discourage confirming things at times). What I want is a special switch keyword that will only ever result in a jump table and give me a warning/error if it cannot produce a jump table for my switch statement. A large switch in a tight loop could be branch prediction hell or it could be lightning fast if it is in a jump table, and I'd like to be able to express my intent at more than just the semantic level, I want to express my intent at the algorithmic level that impacts the hardware.
We have effective UFCS: `auto foo_call(auto x) { if constexpr (require { x.foo() }) { return x.foo(); } else { return foo(x); } }`, it verbose and require helper function for each function you want use.
Herb trying to do good, I can't see why C++ committee so adamant about having ugly syntax like std::holds_alternative (which is not clear at all btw) over simpler syntax
Features, features, more features. This is great, but the hard part is getting this to work with all the other language features. Don't we have like a 100 things that this needs to work with, like constexpr volatile coroutine-generated objects on the right hand side of the "is" expression, just to give a dumb example?
Seriously, just name some random combination of features that can affect types and see if this works with them correctly (also without accidentally adding potential for writing buggy code). Just using the new feature as intended is not enough of a test in a language as complex as C++.
C++ is becoming a bastardized language, like C#. Soon it'll loose its idiomatic style.
I like that.
The committee see to become more and more the ivory-tower that must be avoided. The fallthrough-behaviour is one of the most important features of the switch-statement. It allows us to write more concise code and reduce code-duplication and mental gymnastic. But it is same as with many of the older constructs that some of their behaviour just make them harder to use then they should be.
Instead of not including one of the most useful features (that then would be grandfathered in with much pain a couple versions later) it would be way simpler to have the behaviour in a configurable way.
As an example - why not a specifier after the expression? "explicit fallthrough" - would make it clear that only by explicitly writing a fallthrough-keyword (or attribute or whatnot) would a pattern exhibit fallthrough behaviour. and "default fallthrough" would do the opposite.
having a new keyword ... not sure if that is really helpful.
Yes - "having to scan through" makes it sound bad, but that is not really the case. It would STILL be a switch-statement but with some other restrictions and liberties, but fundamentally it IS a "switch". Heck, by sticking with "switch" and ":" one could easily enhance switch by ADDING "=>" to the syntax and making it denote a none-fallthrough case.
std:.string name = /*...*/;
switch(name){
case "Dave": case "David": case "Davie" => std::cout std::cout
For the explicit fall through continue would be a good fit as it is the "opposite" of break and isn't used so far in switch and it also avoids introducing yet another new keyword
@@pizzawithpineappleissuperi4377 but the switch may be inside a loop so continue already has meaning.
In D we use `goto case` (with an optional expression) or `goto default`.
really, you can't do "is 1 | 2 | 10 || is perfect_square"? :O
`is among(1, 2, 10)`
9:38 I don't like the fact that this syntax is promoting brace-on-current-line style and would look horrible with brace-on-next-line
Too much syntactic sugar. Cpp turns into Chinese.
Please, give us more tools for multithreading, async operations and low level hardware handling.
inspect keyword: Exists.
c#: Oh, come on!
c++ user: I have to pay only what I only use even if it's compile time cpu-cycle overhead. 🤷🏻
Please please consider fixing this. I just don't see any down sides with the polymorphic switch keyword.
This proposal is so bad. Generic programing is not about knowing type. It is about not knowing it. We do thinks for base class and we should not know what child is this class. If we need know if this is int or float we now have if constexpr and it works.
If you want sever switch then simply propose that [[fallthrough]] is always needed when you want it.
Not clear at all. Herb Sutter is a little confusing.
Every language wants to be F#.
In every language community everyone is always referring to how F# does it right and they should strive to be more like it! I guess that is why it is the most popular and widespread language in existence, especially for systems programming
If it wasn't for high frequency trading, C++ wouldn't be as relevant as it is today.
C++ becomes the ugliest programming language ever. Linus Torvalds was right when he said that "nothing is better than C". If you want to be more productive, learn Rust. RIP C++ :(
Instead of "inspect," consider calling it "select." That would be more intuitive/consistent with other languages. The syntax is also super wonky. I understand why you did it but think you are mistaken. You are throwing SYNTACTIC LOGIC out the window, making everything just gobbledygook. There's no syntactic intuition left.
For example, `if(auto i is int = x)` is clearly there to prevent having to do `if(x is int) { auto i = x; ...}` and similar for the others.
THIS IS BEING TOO CLEVER. We have been warned so many times not to be too clever. It makes code ugly and exactly why people don't want to learn C++. Little mental models of syntax that are logical/intuitive are the best asset to making a language teachable, learnable, and desirable. And we are failing this because somehow we think shaving a line or two (or a subline) is worth it?
I'd rather take the slightly less compact code for SANITY any day. Reconsider!
Just trying to parse the chain of values/types is so painful. And it is corrupting C++ away from the beauty of the logic of syntax of C's best bits. Without good reason.
Even in the more complex cases like structured binding, I'd just rather have `inspect(x is [int, int, bool]){ auto [a, b, flag] = x; ... }` than `inspect(auto [a, b. flag] is [int, int, bool] = x)`. It's much clearer, and I gain almost nothing by going with CRAZY CODE.
I wonder whether this is what Andrei meant about "lighter weight syntax." It seems like you're trying to do too much and f'ing up the syntactical logic in the process, making C++ EVEN weirder.
For inspect, the more sane "lighter-weight" syntax would look like this:
`inspect(x) { `
` is int => {/* stuff */} `
` is integral => {/* stuff */} `
` is [int, int] => {auto [a, b] = x; /* stuff */} `
` is [int, int, int] => {auto [a, b, c] = x; /* stuff */} `
` is [0, even] => { auto [_, y] = x; /* stuff */} `
` is string => { auto s = x as string; /* stuff */} `
` default => {/* stuff */} `
` }
Of course, I would suggest changing it to `select(x)` instead of `inspect(x)`.
But the point is, please don't try to smoosh things together into a bizarre, unintuitive syntax!
SIDE NOTE about structured binding syntax: it would be nice if we could do [ , y] = x; where leaving an element in a structured binding empty ignores it. This would avoid silly tricks like discarding variable names and using _ and ___ and ____, etc. in structured bindings in general throughout the language, which is U.B. You use `_` in two very different ways here which is very problematic: both as a discard-variable name in a structured binding, and as a "type wildcard" for "none of the above TYPES." That seems prone to issues. So here I used `'default` instead for the latter. No `is` statement needed or warranted here IMO. However, I do want to be able to do stuff like:
`inspect(x){ `
` is [ , , bool] => {/* stuff */} // x is a 3-tuple of any types up to the last one, which is bool `
` is [ , , , ..., float] => {/* stuff */} // x is a n-tuple of any types up to the last one, which is float `
` is int; is bool => {/* stuff */} // x is an int or x is a bool `
` is integral && std::less => {/* stuff */} // x is of an integral type and less than 100 `
`} `
As for the point about lossy is/as, consider `~is` and `~as`. ~ would mean "equivalent, potentially modulus any narrowing/lossy conversions including implicit ones." You could even have +as and +is to mean "exactly matches." (No conversions at all--even if provided.) Then `as` and `is` by themselves would mean the happy middle ground: "no implicit, compiler-provided narrowing or lossy conversions, but other user-provided conversions allowed."
@37:42 I don't understand the variant code at all. I would have thought it should be like
`template constexpr auto operator is( std::variant const& x)
{ return x.holds_variant(x); }`
and
`template constexpr auto operator as( std::variant const& x) -> auto&&
{ return std:::get(x); }`
Instead, you ignore the types asked for and the corresponding type versions of std::variant methods, and work with indices??? All I can think is that you've added some magic to convert types to indices behind the scenes for variant-like types? What gives?