CppCast - Cpp2, with Herb Sutter

Episode Date: March 31, 2023

Herb Sutter joins Phil and Timur. We catch up on the news about LLVM 16 being released, a new book on initialisation in C++ and a couple of new user groups. Then we talk to Herb about his new language/ alternate syntax, Cpp2, which compiles down to C++ in much the same way that C with Classes compiled down to C. News LLVM 16.0.0 released "C++ initialisation story" - a new book by Bartlomiej Filipek New user group forming in Prague - Miloš Anđelković New user group forming in Helsinki - Timur Doumler Links CppFront - the compiler for Cpp2 "Can C++ be 10x Simpler & Safer?" - Herb's CppCon keynote introducing Cpp2 and CppFront

Episode 357 of CppCast with guest Herb Sutter recorded 29th of March, 2023. This episode is sponsored by JetBrains, smart IDEs to help with C++, and Sona about the release of LLVM v16, a new C++ book, and two new C++ user groups. Then we are joined by Herb Sutter. Herb talks to us about CPP2 and CPP Front. Welcome to episode 357 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today?

All right, Timo. Although I was wondering as you were reading that whether we should have called ourselves Cpp2Cast for this time. Classic Phil. Other than that, all good. How about yourself? Yeah, I'm also good. I finally managed to tidy up my room, so I have a reasonable background now for those who get to see my video for the first time in months since we moved here.

Look good from here. Shame the listeners can't see it. Well, yeah. So at the top of every episode, I'd like to read a piece of feedback. And this time user Aaditya wrote us on Twitter. I hope they discuss how important a role C++ will play in the upcoming AI revolution, maybe due to efforts to optimize distributed training on GPUs or even CPUs. Well, thank you, Aaditya. That's a fascinating topic. And I think we have something about that potentially in the pipeline, don't we phil potentially yes i mean i know one or two people in that space i'm seeing if i can line something up but if anyone does any

specific suggestions for people to have on talk about that then do let us know one other piece of feedback that we got was about the the website move which also if you remember from last time evolved moving the rss feed as well and it seems like it mostly went pretty smoothly except for google podcasts which we seem to get stuck uh took a few days to unstick it and hopefully it's all working smoothly now if you are managing to hear this but are still aware of any issues, then please let us know. But obviously, the chances are low that those two things are going to be the same. But also let us know if you're listening on Google Podcasts and it's all working fine, just to reassure us. Apart from that, I think it's gone okay.

That's good to know. We'd like to hear your thoughts about the show. You can always reach out to us on Twitter or Mastodon or email us at feedback at cppcast.com. Joining us today is Herb Sutter. Herb Sutter is an author and speaker about C++ and programming topics, chair of the ISO C++ Standards Committee, and a programming language architect at Microsoft. He has been the designer or co-designer of a number of standardized ISO C++ features, and in his spare time is the designer of an experimental Syntax2 for C++ and the implementer of the CPP front Syntax221 compiler. Herb, welcome to the show.

Thank you. Thanks for having me. It's great to be back. In your bio there, you call yourself a programming language architect. Does that just refer to C++, CLI, CX, and AMP, or is there other stuff as well? Mostly in the C++ family of languages and extensions, but sometimes most of the program managers and architects in the developer division get to consult on other projects and research projects going on, such as languages for quantum computing, for Project Verona. So it's been fun to have a hand in consulting on some of those projects too, although I'm not one of the designers of those. Sounds fun though. It does mean though that you've had a few runs at designing languages

that extend C++, so I think that's going to become relevant as we get on with the show. Right, yeah. So, Herb, we'll get more into your work in just a few minutes, but before we do that, we have a couple of news articles to talk about. So feel free to comment on any of these if you like, okay? So the first one is big news, I would say. LLVM version 16 got released just, I think, 10 days ago or 11 days ago as of right now.

And it has lots of new features. So we don't have time to go through all of them. But just a few highlights that stood out to me is that obviously the two components that we're mostly interested in as C++ developers are Clang and libc++, but there's also sanitizers and other things. But to focus on Clang and libc++, but there's also sanitizers and other things. But to focus on Clang and libc++,

so Clang actually gets many of the kind of smaller C++ features that were missing until now for C++20. That includes things like capturing structured bindings in lambdas or downward type name. That was that paper where you don't have to type type name anymore in certain places where the compiler kind of knows it's a type anyway, so it just saves you typing. The parenthesized aggregate in it, so you can initialize an aggregate with a round parens

now in addition to curlies, which is very useful for perfect forwarding constructor arguments for aggregates and things like that. And actually quite a few more C++20 features, kind of the smaller ones that have now been added to Clang. They also added a bunch of C++23 features, so that's the upcoming standard that is technically done, but hasn't quite been released yet, but hopefully later this year. So they added features like static operator paren paren and static operator square bracket. They support now a label at the end of a compound statement.

They're permitting static constexpr variables and constexpr functions. And there's a lot more stuff kind of from C++23. Also, the compiler front end has a bunch of new compiler flags, including, by the way, flags that interact with certain C++20 features. Like there is now minus f coro aligned allocation to enable aligned allocation

for coroutine frames. There's F module output to enable the one-phase compilation model for C++20 modules. There's a bunch of other stuff. There's also improvements to diagnostics. There's bug fixes. It's a really big release.

And so that's the compiler, but there's also the standard library, Leap C++. And there we get const express thats.uniquepointer. We get constexprs.complex. We get std expected, which is one of the most expected C++23 features. I had to say it. Yeah, I had to say that.

I'm unfortunately not quite as good at these word jokes as you are, Phil, but I'm trying to learn. I have a good teacher, so maybe one day I'll get there. So yeah, still expected, still source location, and actually much more there as well. So a bunch of new features from CSS 20 and CSS 23 in the Clang compiler and standard library. So yeah, I think that's pretty significant.

That's a pretty big release. It's great to see how the implementations are coming along in conformance. I am still looking forward to full module support in all the three major compilers, but one of these days we'll get to C++20 complete everywhere. But we're getting there, and this is great progress. Yeah, this is a huge release.

As Tim was already hinted at, let's give it a taster, but talked about the compiler and the standard library, but internally as well, it's changed a lot. And kudos to everyone that's worked on this because it's been a massive job. Speaking as someone that builds on Clang tooling, working at Sonar, just a bit of a heads up, actually.

A lot of changes internally, breaking changes, for positive reasons. But if you do depend on Clang tooling, especially the ast matches so they've actually changed quite a lot and it was a much bigger job than we expected to to catch up with that but as a result it's actually improved our code base even fixed some latent issues so all worthwhile but just make sure you set aside enough time to do that if you're doing the upgrade yeah yeah here at jet brains we also depend on several pieces of clang tooling so yeah i know a lot of people do so

right so um there's a another release which is not really a software release but something else that caught my eye this week which is a new book that's been released by bartholomew philippek called c++ initialialization Story. So I've actually helped him review this and I think it's a really nice piece of work. So I'm very happy that it's now being released in print. I think it's been available for a while kind of online as a kind of preview version or something,

but now you can actually order a print paperback edition as of this week. And it's 295 pages on initialization in c++ and everything you need to know so maybe um i don't know how we got there that we do need 295 pages to explain this for comparison k and r second edition is just 272 pages for the entire c language and its small standard library. Yes. But I have reviewed this book, and I think Pat Vormey did a very good job there.

He just really explains everything you need to know, not just about initializing variables and members, but also constructors and everything that that involves and all the different parts around this. He explains half of the language there and starting from this theme of how do we initialize objects and yeah i think it's a really good book i definitely recommend it to people who are kind of struggling with those aspects of c++ and yeah i hope it's going to be successful initialization is so fundamental it has tendrils

everywhere so you do end up if you're doing a thorough deep dive, you're going to touch more of the language. Still, it seems like this is a poster child example of where there is room for simplification. Yes, and we're going to get into that. I think it's a poster child for iatrogenic complexity, which is the form of complexity that arises from trying to make things simpler every time we've had an attempt to making initialization and c++ simpler we've actually made it more complex yes i might be responsible for a tiny bit of that no comment oh and i as well but yes i know what you're talking about it's it's like oh um we're fixing this this problem and then yeah we have like 20 new rules and five new core issues

because there's certain aspects of this that we haven't really considered. And yeah, it's a bit of a hairy situation, but I don't expect any more initialization changes in the upcoming standard, but let's see. But it's a great book and very readable. It's great to see an important subject a it's a great book and very readable it's it's great to see an important subject tackled by an author is very readable and brings the the examples and

points across very well yeah he definitely does that and then the last piece of news is actually that we have two new c++ user groups that have been founded so the first one is actually um in prague the Czech Republic. So that's actually another email that we received from somebody who was listening to the show, Milos Angelkovic. I hope I pronounced this more or less correctly. And Milos writes, Hi, I have fairly recently moved to Prague for work, and I'm trying to organize a local user group with regular, probably monthly meetups. As a first step, I have created a Discord server to see if people are interested and also to get some help in organizing this. So I would really appreciate it if you shared the invite link on

your podcast. And this is my LinkedIn post, so people can find me in case the invite link expires by the time they see it. And finally, let me stroke your egos by saying that I have only recently discovered your podcast, but I do like it. Well, thank you very much, Milos. We are certainly going to share the invite link to your C++ Park Discord, as well as your LinkedIn profile on our show notes. And yeah, good luck with the new user group.

Yeah, exciting. And the other one is actually a very similar story. I have very recently moved to Helsinki, Finland. And that's where I live now, as of three months ago. And I'm also starting a local user group here because I discovered that in the Helsinki area, there's lots of C++ developers. There's lots of companies doing C++ from different industries,

but there's no Meetup. So I decided to change that. So I also have a Discord server that you can join. I have a website now, meetup.com slash cpphelsinki, where you can join the Meetup group and be informed about events that we're going to schedule. Hopefully, we're going to be able to establish a monthly in-person meetup as well. We also have a Twitter account at CppHelsinki that you can follow.

And if you do live in the Helsinki area in Finland, please follow and join all of those. And we're actually looking to have meetups, hopefully very soon. And they're going to be open to anybody interested in C++ kind of in the wider Helsinki area. Currently, we don't actually have a room yet or an event space where the actual meetup can happen. So I think the first one is probably going to be just some socializing food and drink and stuff like that.

But in the future, hopefully also C++ presentations and talks and content. I do need financial help for that, though, for making the event space happen. So if you are a company doing C++ in Finland, and you have a room or an event space that you can once a month, or maybe it can also rotate less frequently. But every once in a while, you have a meetup space that you could let us use for a couple hours after work or um if you want to support the meetup either by contributing towards renting a room or just sponsoring free drinks or whatever uh that would be very much appreciated so please reach out at cpphelsinki at timor.audio and let's make this happen now i just have to jump in those who are listening will not

see what i see which is the timor as you're saying this you are wearing a cpp north shirt but toronto is not as north as helsinki the last time i looked no toronto is actually so this should be cpp really really north yeah so toronto is actually i think the same latitude as Venice or something in Italy. So it's surprisingly not very far north by European standards. And yeah, Helsinki is pretty far north. It's far north enough that in summer, we get 24-hour daylight where it never gets dark.

So if you're looking for a name, CPP really north. All right. Yeah, that's a great idea so exciting times again yeah and uh obviously we're concentrating on these two new meetups here that really need support people to come along and event spaces and that's true of all the meetups around the world even even those that are well-established, speaking from experience running C++ London, where it's relatively easy, but we still struggle to find event spaces and have to chase speakers. And anything you can do to help around the world is always appreciated. All right.

So if you've been following this podcast in recent months, you know that we've started a series on the so-called C++ successor languages that were announced by various people last year. So we had an episode with Jimmy Racordon a few months ago about the vowel programming language. We had an episode with Richard Smith last month about Carbon. And this week, we are concluding this trilogy with Herb Sutter and his project CPP2 and the associated compiler, which is called CPP Front. Now, interestingly, Herb, you don't call CPP2 a successor language, but you rather call it a new syntax, don't you?

I kind of object to that. Yeah. Just for my work, because I'm trying not to do that. Right. And also CPP Front isn't strictly a compiler, is it? It's actually a transpiler, which translates the new syntax for the old syntax or the current C++

syntax, and then you can compile that with a regular C++ compiler, right? So that's, yeah. Well, yes, it is a transpiler, but you may recall the C front from which it takes its name back in the day. Bjarne was always very vociferous that a transpiler is a compiler.

It's doing all the phases of translation, and then it's just lowering to another language of source code instead of lowering to IR. But yes, that's the approach. And then leveraging, it keeps us honest in making sure we stay compatible with C++ because we do have to talk to a real C++ compiler with today's syntax at the end that we lower to. Yeah, so that's quite an interesting approach that you are taking there. So I'm looking forward to digging deeper into that today. Thank you so much again for finding the time to join us for this discussion. I guess my first question is,

when, how, and why did you come up with this project? Well, the when was about 2015. So right around the same time as we had, Bjarne and I and a few others had taken a run at putting together the C++ core guidelines, assembling them in one place. The goal there was to come up with a way to simplify C++ by adding a few key things that are missing, which have become the guidelines, the GSL support library.

That's it, the guidelines support library, and some of which has now been standardized. So the original array view is now the standard span largely. And that exposed the limits of how far we can get toward specifically safety as a goal and usability without doing a breaking change at the language level, without doing a major evolution of the language. And once we're seeing what the limits of that were, well, that's when I started noodling on, okay, well, what would it look like if we did take a breaking change, but a compatible one, if such a thing is possible, in the language? And to some extent, C++ has been doing that for some time. We have been adding replacements for features, such as using instead of typedef,

that really subsume all of the existing feature, or in some cases, subsume parts of the uses, and then you have to teach which one to use where. So I thought, well, what would happen if we actually took a step back and did that across the whole language and said, can we simplify the whole language? And so I started noodling on it,

and a lot of the work happened in that first year, 15 to 16. All right, and so is that why you chose to go for this new syntax approach, to stay fully compatible and to purposefully not invent a new language, but invent, like, just say, okay, we're going to have a different way of spelling things, but it's still going to be C++ or a form of C++ that's kind of backwards compatible. Yeah, I think that's a good way to say it, because if you do a greenfield language design, there are many more things I would do. I have other ideas on how to simplify loops and things like that, but they're not appropriate to this goal. And so I threw out those ideas early. The goal here is to say, well, what can we do to reboot or reskin? If you think about programs that allow skinning, you're still using the audio engineering program, but it's got a different skin on it, for example, a different UI. But it's still the same engine.

It's still the same power and control, but presented to the user in different ways. Some of the knobs look similar. Some of the knobs can be abstracted differently, but they map to the same underlying things. And so that's the way I approached it. Two of the key things, and the same thing you can see happen in the Objective-C to Swift transition, for example, is that that compatibility constraint up front really means that you have to have the identical object model or a superset of it, just as, you know, Objective-C and Swift, one is a superset of the object model, and the lifetime model. So what do pointers and what does lifetime of program objects look like?

And that's why we saw ARC, automated reference counting, added to Objective-C. And then I think it was a little after that, the Swift came along. And then we go, ah, that's where that came from. They were already building the bridge towards Swift before Swift was announced. But you need some compatibility in those basics. Otherwise, if you invent a new object model, you've got a nice, shiny language with a new object model, and you're going to be wrapping forever. That's generally where languages end up, is wrapping and shimming and working on compatibility for a long, long time. So out of the gate, one of the key things was to be fully compatible, especially binary compatible.

And so would you say that's the main difference to projects like Val or Carbon or the unique selling point of cpp2 that you you have this like full full compatibility that's one really major and important thing for me and it's a constraint right but constraints are liberating because they direct creativity in the directions that matter and so we can then be creative in other ways but so compatibility 100 full fidelity compatibility, typically even with macros with C++ is a primary goal. And for example, that means building on C++ 20 modules, not designing a new divergent module system, things like that, that then have

to get mapped back and forth to or create divergence. So we want to avoid that divergence. And then also making sure that we're continuing in the same path as C++ is already going. So it's important to me to be really strongly rooted in what we already know works well in C++. The advice we already give, when we say don't use this feature, we already say use this instead and automate that, make the right things the defaults, encourage people to use the things we already encourage them to use. So it's still C++, but just nicer, but still recognizably C++, even if the syntax may be a little different. So that's the goal that I thought was important to

me. I wanted to end up with a language I wanted to write C++ in. So you mentioned 100% source level compatibility with C++. Does that extend to within the same file? Can you mix CPB1 and CPB2 in the same file? So the 100 compatibility has two parts 100 binary compatibility always on 100 source compatibility always available but you only pay for it when you need it right so if in the future if this ever goes anywhere because right now it's just a personal experiment but in the future if this ever goes anywhere, because right now it's just a personal experiment, but in the future, if this ever goes anywhere, you could imagine having much simpler tooling and faster compilers for a file that has only the new syntax. But you also have the ability to have a file that mixes, and this works today, mixes today's syntax for you can define a class using today's syntax and then define the next class using the syntax too. And those will work fine in the same file as well.

But of course, then you're already, you're also using, you know, 110% size compiler because it's understanding the current language plus the 10% sized language in addition instead of that. But then you could imagine in the future that tools would be able to deal with just the 10 sized language and get get tooling light up and build speed improvements and things like that so i guess i mean it's a bit difficult to discuss syntax on a show that's audio only but i guess that means that the cpp2 syntax is you know different enough that a compiler would be able to immediately recognize this is a CPP2 function declaration or a CPP2 class declaration, and this is a C++ functional class declaration. Yeah, and it's really simple. Every declaration and definition in CPP2 is name, colon, type equals value. That's it. And already in C++, just the name colon is already pretty unique.

It can appear in places like a case statement, but not at namespace scope usually. In fact, one of the places that it can appear at namespace scope today is using colon colon std, for example, something like that. and that's easy to realize that oh that's not a a cpp2 declaration that's a c++ keyword and it's it's two colons it's a using namespace right or it's a using declaration there's very few collisions with that because colon is uh is largely unused especially at namespace scope so just introducing things by name colon already makes things very unambiguous. And so one of the first things CPP front does is it goes through your source file and just

identifies all the CPP2 parts exactly that way. And all the CPP1 code, it just passes through unchanged and it compiles and translates, you know, lexes, parses, does semantic analysis, and then lowers just the CPP2 syntax code. Right, and I guess you don't have a problem with things at Blockscope, like distinguishing a declaration of a local variable and a label, for example, because when you're in a function body,

you already know that you're parsing one or the other, right? So you don't run into that. And when you're in a function body, so this is the compatibility and the ability to mix syntaxes is at the top level. So once you open a namespace using or a class using today's syntax, you stay in today's syntax. You don't just arbitrarily mix line by line, but you can mix like 10 classes written using today's syntax, and then another one, not inside, but beside using syntax too. And then once you're in that world,

now you have a consistent syntax where colon always means I'm declaring something. So that's one, just from a syntax point of view, it's easy to get wrapped up in that, oh, it's a different syntax. Syntax is the tool that carries the semantics, but it's the most visible thing. So people will, of course, focus on it. But even the syntax ought to be clean. And so one of the things that I, the design points that I hew to is wherever possible, have every piece of syntax so in this case the colon always mean the same thing and have nothing else use that syntax so in cpp2 a colon always means i'm declaring a

new thing even if it's unnamed if there's no identifier before it so if i'm writing a lambda an expression function it's exactly the function syntax but just an expression scope without a name in front of it but it's exactly the same syntax, but just an expression scope without a name in front of it. But it's exactly the same syntax. So colon always means I'm declaring something new and it has no other meaning. So even for labels, you'll notice that with, because we have now named break and continue, I added that a month or two ago, labels for loops follow the same pattern. You declare the loop name with name colon. And so that makes it nice and clean and consistent. Yeah, that sounds really

cool. It also sounds better and slightly different from, for example, in JetBrains, we mix Java and Kotlin a lot and they're also freely compatible in many ways, but you can't mix them in one file, for example. That's not really a thing.

And also the other thing is, for example, Carbon, which we discussed with Richard just four weeks ago. They also strive for seamless interaction in the sense that you can use a Carbon class in C++ and use a C++ class in Carbon. But I think there's some stuff that doesn't quite translate. For example example they have like different generics which don't really map to like C++ templates and then

or they don't have overload like overloads in the same way as we have in C++ and then it doesn't quite map and I think that maybe I'm misrepresenting this completely but from what I remember it's not quite clear how to resolve this. Whereas I think in your project,

it's kind of just always there. It's like one-to-one correspondence that's like built in, right? That's correct, yeah. Oh yeah, that's really interesting. And I think that level of compatibility is really important for adoption and the level of familiarity.

So some things will look different, but the concepts are very similar. And where you have some new concepts, they're generalizations of the things we already have today, such as the biggest one probably is parameter passing, where you declare in, in, out, out, for example, and moving forward.

Well, we already have those concepts. We just spell them using conventions. And so, yes, there are six new words to learn, but once you know them, you know them, and they work everywhere, and they replace all the conventions. And so, yes, there are six new words to learn, but once you know them, you know them, and they work everywhere, and they replace all the conventions. And they're familiar in the sense that you know that, oh, this is just a word for the convention I already know. So, for example, today, if you pass a parameter by a reference to non-const, you say have an X ref parameter. Well, that could be an in-out parameter or an out parameter and in cpp2 you

can just say which it is and they both map to x ref so it's a familiar oh this this uh compiles down to basically an x ref and but now i can actually just say what i mean and say what the data flow direction is so that's kind of a good good example of where I try to keep the balance between compatibility and familiarity, but also expressing things in a cleaner way with more abstraction. So it's not a greenfield language design. It's still rooted in C++ and expressing the same things, but the goal is in a nicer way at a key to that is being able to express your intent to directly say what you intend you mentioned a couple of things there that sound familiar because you've i think you've also raised them as proposals for inclusion in c++ speaking of the

in-out parameters are there many features in cpp2 that you've also proposed for C++? As I mentioned in my CPPCon talk, a lot of this is stuff you've seen before because except for the syntax itself that brings it all together, every proposal and every talk I've given in the last seven years has come from this work. Just I presented it as an extension using today's syntax. One of the hopes is that as you unify these, so the second syntax is one way to look at it is it's a way to bring all these things together and show how they interoperate well and hang together and reinforce each other

and can be used together to get combinatorial expressiveness with a small number of general features, that will show the value of better together. But already, I've been bringing each of these proposals out to see, you know, is it something the committee agrees is a problem we're solving? How does the community react and talk audiences to a solution along these lines? And so it's been important to me to vet each of these major things before just having this big foreign thing burst upon the world. I have one more quick question.

So some of the stuff that you said about kind of changing the default and changing aspects of the language in a breaking way while preserving this kind of backwards compatibility reminds me a little bit of Vittorio Romeo's proposal that he discussed on the committee a few years ago about epochs, which is a little bit different, but it feels like there's some similarity there where he was also saying,

why don't we have like a new version essentially of C++ and deliberately break stuff and then you can be on the old epoch or on the new epoch and, you know, somehow they would kind of interoperate. And it feels kind of similar. Is that kind of, how is that different? Well, and so that's an excellent question. And of course, Vittorio's work is also cites other previous work, notably Rust editions, but also other languages. If I had to boil it down to one thing, I would say I love Vittorio's epochs proposal, except it has one letter too many. It shouldn't be epochs. It should be epoch because I worry very much about taking a significant breaking change more than once every 30 years. I think you get a chance about

once every 30 years to do what we're doing. And there it's important to really take advantage of it. So for example, if we're going to do something like additions or epochs, what are the limits? Like if you look at some of the proposals, including the kinds of changes allowed in, say, Rust additions, do they allow us to actually achieve all the things we want to achieve? For example, do they let us change defaults? Do they let us remove special cases? Do they let us replace something with a parameter passing with a generalized abstraction? And the answer in some cases is yes, and some is no. So by focusing on, well, if we get this chance once every 20, 30 years, what can we do well to get the maximum

advantage in taking all the learnings that we've already had and say, now let's apply them once we get a chance to take a breaking change and really get the benefit from it and make sure we do it in a compatible, adoptable way. That, I think, is the right thing. So I think that Victorio's proposal is exactly nailing the problem. It is showing the appetite for, there's a problem here that needs to be solved. We need to break the strict backwards syntax compatibility constraint somehow. And I totally agree with that. And I do agree with an epoch. I'm not sure that epochs work.

I know that my understanding from the Rust community is they have been working, I think about once every three years or so, I should check in again, in the Rust community. They are also 1% the size of the C++ community. So you have more flexibility when you have fewer users. And Rust is growing. They're getting more users. But as you start, part of our chains of backward compatibility

is because we have so many millions of users and so many billions of lines of source code. You know, customers are great, but they're also a ball and chain sometimes. And so the reason that C++ has that problem is because of its popularity. So once you become that popular, it becomes much harder to do things like additions. So I do look forward because, you know, somebody maybe is able to crack that nut. I look forward to seeing if they could do better. I'm just skeptical. And it seems like it's the kind of thing we get to do, the cleanup pass we get to do once or twice in our careers. So we should make the most of it. So what you're saying is nobody uses C++ anymore,

it's too popular. I think clearly people are and will continue using C++ for a long, long time, no matter what we do. Can we make it more pleasant? And can we help them solve their problems better at lower cost with more safety, with fewer accidental bugs, with less to learn and teach as we onboard people and have to train them. And as we, who've been doing it for way too many years, still have to remember way too much every time we pick up the programming keyboard. You need a book on initialization. So you already mentioned safety there,

and this is something that I i would love to dig uh deeper into but before you get to that i think phil has a message from one of our sponsors so this episode is supported by jet brains and jet brains has a range of c++ idees to help you avoid the typical pitfalls and headaches that are often associated with coding in c++ exclusively for cpp castast, JetBrains is offering a 25% discount for purchasing or renewing a yearly individual license on the C++ tool of your choice. That's C-Line, ReSharper, and ReSharper C++, or Rider. So use the coupon code JetBrains for CppCast during checkout at www.jetbrains.com.

So you said that Cpp2 is your personal experiment or experimental project, but is there anyone else helping you with Cpp2 and CppFront, or is it really just you? Well, it really was just me until the point where I gave the CppCon talk and then open sourced the GitHub repo. I'll overshare a little bit. The GitHub repo initially was opened just so I'm showing my work so people can see it. Issues were disabled and PRs were enabled only because I could find no way to turn them off. Then people started submitting issues as PRs because that's the only thing there was. So I turned on issues that led to some good feedback.

And also we've now had several contributors, Philip, thank you again in particular, but, but several who I acknowledged in my January blog post, it was a mini update about this and who've been contributing things. So especially the string literals work. Thank you, Philip.

And the raw string literals features like that have been added by others. So it's still mostly my work, and it's still on my nights and weekends. But it has more contributors, which is something I didn't actually expect or plan for, but it is appreciated. Thank you. Right. So, Herb, you already mentioned the word safety a couple minutes ago and so if you have that on your bingo card you can click it off now yeah exactly so i

want to kind of just dig dig a little bit deeper into that because it's been such a hot topic this is something we've discussed at length with um you know dmv uh about val and with richard about carbon and we actually had an episode last time dedicated entirely just to kind of safety and security in C++ with Andreas. So let's talk about safety. There is type safety, memory safety, and I guess you can divide memory safety

further into bounce safety and lifetime safety and initialization safety, which is what the book is about that we mentioned earlier, and object access safety, and then there's threat safety and initialization safety, which is what the book is about that we mentioned earlier and object access safety. And then there's threat safety and arithmetic safety. And, and so that's that.

And all of these are potential sources of undefined behavior and C++, which is a problem for many people. Can you give us like a brief overview of like, which of these PP2 actually solves or aims to solve and how. And obviously, I don't expect a comprehensive... Just give us a little taste of what the idea is. For the reasons I gave in the CPPCon talk, when you look at the security vulnerabilities that are being exploited, they're playing the hits. Type safety, bound safety, and lifetime safety, initialization safety.

And so those are the ones that I'm initially focusing on. But if you look at the repo, there's also stuff about arithmetic safety. Thread safety is also important. But those first four, type, bounds, lifetime, initialization, safety, are a focus. And so one of the things I was very proud to be able to demo on stage was guaranteed program meaningful initialization. So for some of these, I actually aim to provide a guarantee, in this case, that every local variable will be initialized before it's used, but not necessarily at the declaration. Because at the point you have to give it a name, you may not yet have a value for it. You basically need to compute a value, for example. But you need to declare the name for other reasons, not most of the time, but sometimes.

And I believe I can guarantee that you will always use it, never use it before it's initialized. You will always initialize it before it's used, which is, I think, super important. But for some of the others, I'm going to be a bit of a curmud reason I say that is because even type-safe languages like C-sharp, which I love, it's a great language, isn't safe. And in the sense that, for instance, you have finalizers that can resurrect objects and you have other sources of unsafety where you can use after disposing an object. So use after destroy is totally a thing in C-sharp, even though they have a garbage collector, because object safety object lifetime is not the same thing as the underlying memories lifetime. They've got memory safety, but not object safety. So you're just reading a garbage value, but it's not U contain legit values, which is, so you do have some guarantees, but, and I'm not saying this to pick on C sharp, Java has the same issue with

their finalizers. I'm simply pointing out that even when you try to do formally provable things, you're never going to get to a hundred percent. You can always write bugs, but there's also safety categories that are present, safety, vulnerability, and violation categories that no language will ever always be able to protect you from. My goal, though, is to say that we absolutely need to make a large improvement. And I'd say at least a 10x improvement in simplification and a 50x improvement in safety. But 100% is not necessary. And the reason I say that is because, yes, we have all these CVEs because it's so easy to write uninitialized variables in C++. Oh my goodness, is it easy. Use after free, buffer overruns. It's so easy to do that, even when

you're trying to pay attention. And we absolutely need to make that better. But it's not necessary to make those things impossible, even with an unsafe escape hatch. It's not necessary because if today's problems manifested 1% as often as they do, if it weren't so easy to do them, if it were just like 1% of the problem, we wouldn't be having this discussion. Nobody would be bothered about it. It would be manageable. So we don't have to drive that down to 0%, but we do have to drive it down to something closer to 1% or 2% of the current frequency of these exploits. And so that's why I'll take the somewhat controversial view, and I know not everyone will agree, that a formally provable type of memory safety is not actually necessary. It's fine if

we also get that for some things like initialization safety, but it's not necessary because A, you can't always get it anyway. Even in languages like C-sharp and Java, there are safety holes in the language. And by design, it's not just implementation bugs. And second, it's not necessary because what we really need to do is drive these exploits, these vulnerabilities down to the noise. If we've done that, we can celebrate and say we've done our job and had a good decade.

Sounds reasonable. Yeah, that's interesting. Think about that further. Yeah, I need to think about that too because Rust or VAL, the other new language that further. Yeah, I need to think about that too, because Rust or Val, the other really new language that's been proposed, they have a programming model

where you have this kind of guaranteed memory safety with Rust's borrow checker or with Val's kind of mutable value semantics where you can actually reason about object lifetime safety Bell's kind of mutable value semantics, where you can actually reason about kind of object lifetime safety and those things in a formal way. And that's being presented as a major selling point. So now you're basically saying, but that's not a thing, if I understood you correctly. So

there's, I think, something I'm missing here. You know, let me be clear. That's totally fine. There's nothing wrong with pursuing that. But it also imposes great constraints. What I'm pointing out is that that level, which can be achieved with trade-offs, that level is not necessary to solve C++'s problem. What we need to do is we need to get like a 50x reduction, but not an eradication level reduction of the CVEs because you're never going to get to zero. You have CVEs in Rust, for example, today. CVEs are reported security vulnerabilities. Every language has them.

You're never going to drive those to zero. What we absolutely do have to do is drive them down by two orders of magnitude because C++ is really full of landmines today. So maybe that helps. I'm not against formally provable guarantees. such constraints that it makes that there are other trade-offs such as programming language difficulty of use and things like that, or a foreignness to the C++ logic model. Whereas I'm just saying that it can be good enough and not in the I'm settling for good enough, but really can be good enough to have a 50x reduction and have it not be formally

provable down to zero. I think it actually makes sense to me now what you're saying. It kind of ties in with what you're talking about earlier about like kind of compatibility. Because for example, if you have, I guess that's one of the things that you're saying where you're giving up things. Like for example, if you have a borrow checker,

you can't really have iterators, right? And things like that where, yeah, you're giving up whole paradigms and you have to kind of reinvent how you write code which i guess is part of the appeal of rust but also it creates this like big problem of but how do i migrate my code base to that if i'm already doing c++ and i guess kind of you're catering to that kind of a lot more while also, you know, proposing a massive improvement about safety too. So I guess, yeah, it's a trade-off that definitely makes sense, I think. So thanks for explaining that because I watched your keynote, but it wasn't clear to me at the time.

But I think now it's clearer to me. So thank you for explaining that. We talked about trade-offs there. One of the trade-offs is is always uh when we're seeking performance so where do you fall on performance is there no trade-offs or no overhead i i think if if we any syntax or language that does any any syntax, let's say, alternative syntax for C++ that does not prioritize performance and the zero overhead principle, that is unquestionable and necessary. If it doesn't have that, it's not C++ anymore.

We must have, what makes C++ C++ is not its syntax. What makes C++ C++ is the zero overhead principle, that you don't pay for what you don't use. If you don't use a feature, you don't pay for it. But also that when you do use it, you couldn't reasonably do better by hand, by writing the code manually. That has to be preserved.

Violating that is a non-starter. It's not C++ anymore if we violate that. So, for example, in CPP front, there are switches, which thanks to user feedback, I've now made the default but still have an opt-out that I presented on stage at CPPCon to automatically do subscript checking, to do null checking, so a couple of things like that. And of course, checking isn't free. Dynamic checking is not free. Some of the checking is, a lot of the checking is static, but some of the checking, like bounce

checking, some of it must be dynamic. When I presented this on stage last fall, there was a switch where you would opt into it. So you would get the performance always by default, but you could opt into the safety. I was since convinced by repeated issues and pull requests that it's fine to have that switch, but make it the default and always provide a way to opt out, that also still satisfies the zero overhead principle, which is you don't pay for what you don't use because you can opt out when you don't want it. But safety by default is important. So thank you to those who provided that feedback. But I think that might answer your question about, yes, performance, you must always be able to open the hood and take control. And in the future, I plan to add ways to specifically suppress safety rules to get a specific job done when you need to. There's a design note on the repo wiki about that. So github.com slash hsutter, perpsutter slash cppfront on the wiki. There's some design notes, one of which is about that.

But I think it's really important that I'm a C++ programmer and nobody is going to take my ability to open the hood and take control out of my cold, dead hands. I mean, I am going to keep that forever because that's important to me as a C++ programmer. And I am writing C++ 2 and C++ Front primarily for myself, but everybody is invited. I think a lot of people will like to hear that about performance and everything that you said. I guess the other big selling point of C++ apart from performance is portability, right? So C++, you know, we have at least three major implementations. We have other implementations as well. It runs on Windows, Mac OS, Linux, mobile platforms, embedded, bare metal, all kinds of platforms where I don't even

know how they represent integers, but somehow C++ runs there too. And so I guess that's a huge selling point. So the question that we ask the other language designers and that I'm also going to ask you is, are you planning to support all of these platforms and major compilers that C++ supports today? Or is there any compromise that we will need to make to get the benefits that you're speaking about? They all already work.

So we regularly, I demoed on stage and I would have demoed Clang and GCC if only my WSL subsystem hadn't crashed on stage and I didn't know how to reboot it then. I rebooted it five minutes later and it was fine. But CPP Run already works with all three major compilers. The regression tests that get checked in always run with msvc gcc clang and now apple clang thanks again philip for providing because

apple clang is a bit divergent in a few ways and so there's a set of regression tests for apple clang as well it just works i haven't tried every single compiler and platform but every compiler and platform i've tried works and i'm committed to making it work. So that means CppFront itself compiles with all those compilers clean at high warning levels, and also the code CppFront generates compiles with all those compilers cleanly at high warning levels. So yes, absolutely, it's important to me to support all of those, and I already do. So I have a question about that, but I need to ask another question first.

So remind me to come back to it. In your CppCon presentation, you said that the code that's generated should be sort of close to what you would have written by hand if you were trying to write it so cleanly and optimally. Yeah, and that's hard. Yes, and I'm still doing that. And just yesterday, I checked in some improvements to that. We were adding extra spaces, and I was like, oh, that's ugly.

And I keep meaning to fix that. And so I've improved some of those again just yesterday. It's a running battle. But if you don't keep up the running battle, you will cede the battlefield. And so, so far, so good. Now, some things do generate more, like inspect statements, like inspect expressions, generate long if constexpr, nested if constexprs with lambdas. All on one line.

So they scroll off the side of the screen and it's generated code, but it is still legal C++. It's doing the thing you asked, but it is still legal C++. It's doing the thing you asked, but it takes a bit more room. Most things map closer to one-to-one and you'll more see things like the prefix, the postfix operators map to CPB1 prefix operators, things like that. Right. But yes, it's very important to me. And part of the regression tests are to make sure that that doesn't get disturbed, that the formatting is still similar.

And, you know, there's something we've been dancing around. Let me just say it clearly because I think it addresses some of these issues about using old and new syntax in the same source file, compatibility, and now the prettiness of the code as well. My goal absolutely is a TypeScript for C++. Nobody has tried to do a TypeScript for C++. Nobody has tried to do a TypeScript for C++. That is, JavaScript had many super, super useful, incontrovertibly useful, unquestionably, and also incontrovertibly, unquestionably, horribly complicated and had lots of features that people shouldn't use. And the usual joke and the usual image that Anders Heidesberg liked to put on a screen

is, here's this big, thick book on JavaScript. And then there's this tiny little thin book beside it on JavaScript, the good parts. We can do... Once I showed that picture to Bjarne, he immediately said, hold on, took a picture on his desk of the C++ programming language, his book, and a tour of C++, also his book, to show the same difference. Just to emphasize, and he sent me that picture, which I've used. So thank you, Bjarne. To point out, we have the same issue with C++ as a small language, a cleaner language trying to get out, where there's problems with the big incumbent, C++ and JavaScript, and a desire to do a 10x improvement. For JavaScript, there were several attempts at doing that.

One was Dart, for example, which was an incompatible improvement, but it still did improve many things. And then there was TypeScript, which emphasized compatibility, including that every JavaScript file was a TypeScript file. So just like, remember, with CPP front, with Bjarne's C++ compiler, the very first thing you could do is rename any.c file to.cpp, and it would still compile. And then you could add a class, one class, and start seeing benefit. TypeScript did what Cfront did, what Bjarne's Cfront did. You could rename any.js to.ts, and it would still compile. And you could add one type specification and start seeing benefit.

And if you ended up not liking what TypeScript was doing, it too is a transpiler. It's a real compiler, but it emits JavaScript. You can always walk away with your JavaScript code. I've seen the hashtag no regrets being used to describe it. I could always walk away and have my code. This is exactly the playbook I'm trying to follow for C++ to see, can we do a TypeScript for C++?

And I have seen lots of efforts to do a 10x improvement in C++ that follows the Dart model, but the Dart model requires incompatibilities and then bridging. And by not having that level of compatibility that you can mix, that you transpile to the original language, that you can mix and match in the same file the original language, because you don't have that, that creates barriers to adoption. It creates barriers to compatibility.

And so to me, a major way of looking at this is, is a given effort to try to improve C++, are they on a Dart for C++ plan or on a TypeScript for C++ plan? I am firmly committed to being interested only in a TypeScript for C++ plan because it's the one that I think is most likely to succeed. And even then may fail, but I think it's the one that's most likely to succeed and be adoptable and used and actually make a difference. So what you're saying is Dart missed the bullseye? You know, and Dart had other issues. I don't mean to paint things badly with that because there are political things too. I'm not familiar with all of them and I'm glad I'm not. But just from a technical level,

compatibility is super important. And TypeScript really nailed it. By the way, let me just give a shout out to the main TypeScript designer who was, drum roll, Anders Hausberg, who was also the designer of C-sharp, the main designer of C-sharp, who was also the main designer of Delphi, who was also the main designer of Turbo Pascal. I don't know, I don't think there's any other human on the planet who has designed multiple million user programming languages. This is an exceptional mind. And I think Anders knew what he was doing when he created a TypeScript because he didn't just clone C Sharp and what C Sharp did in competing with Java, for example, and other languages. He looked at the requirements for,

okay, what does it take to improve JavaScript? And he did something that was very different. Yes, superficially, some syntax looks the same, but you could see he was applying his genius there to say, what are the problems here that need to be solved? Because they're different from the problems that C Sharp was trying to solve. And so I think it's genius there to say, what are the problems here that need to be solved? Because they're different from the problems that C Sharp was trying to solve. And so I think it's important to, again, say,

if we're going to improve C++, it's not just going to be a clone of some other effort, but what are the unique problems in C++ we want to solve? What are the compatibility constraints in C++ which are going to be a bit different? For instance, the difference between binary and source compatibility, which doesn't exist as much for JavaScript. And account for those, to be a bit different. For instance, the difference between binary and source compatibility, which

doesn't exist as much for JavaScript, and account for those. But how do we solve those in a compatible way? I think Anders nailed it and hit it out of the park. And I think everyone on the TypeScript team, to my knowledge, was surprised at how quickly it was embraced and took off. But that's because it really solved the problem people needed and the compatibility made it adoptable. And that is so, so important. That's a really good point. I do want to circle back to my earlier question that I said I'd get to, which is do you find that with trying to generate decent C++ code from CppFront,

that's in tension with the goal of compatibility with all the main compilers because you're going to have to target a subset of the language that they all support? Or is that really not an issue? It's not an issue because, yes, there is such a subset, and that subset is C++20. So what's currently supported? Well, so right now I work with all, the CPP front works with all the major compilers,

the fairly recent version. So if you have a GCC, Clang, or MSVC, any version in the last two years or so, you should be fine. I mean, it works with GCC 10 point something onward, which is like 2020 onward, with MSVC from I think 2020 also forward as well. So last three years, if you've got a compiler that was shipped in the last three years, it should work fine and warning clean. That doesn't mean that, like I said earlier in the podcast,

I do look forward to everybody supporting modules fully. In the meantime, I have workarounds for that to simulate module support in the compilers that don't have it. But that's pretty much the only exception that I rely on, that C++ Front relies on in its code gen. Now, let me just say, though, C++ 20 is super important. I mean, it was a big release, but it had features that make my job for C++ Front much easier.

I could have done C++ Front before C++20, like for targeting C++14 or C++17 compilers, but it would have been much harder. And I'll tell you exactly why. If constexpr requires is so, so useful and important. So requires expressions, if constexpr, as well as generic lambdas and some of the improvements, other improvements that have come in C++20. Without those kinds of things, yes, you could do enable if, but oh my goodness, you would not love that generated code. With if constexpr and requires and a few other key features like that, it really enables the kind of code that I need to be able to generate.

So thank you C++ Standards Committee for C++20. And by the way, I think it's also taught me, because I'm learning from doing this you learn a lot by trying stuff and seeing what doesn't work and then trying something else one of my learnings was just how important if constexpr and requires expressions are well that also teaches me that any successor language attempt or parallel language attempt that tries to only be compatible with C++17 has created a big hill for themselves because to be part of the C++ community, you have to be compatible with the latest standards.

So that's going to require C++20 and 23. But also it means you don't get to take advantage of C++20 and its important features. So I think it's really important for, to be a viable evolution, even a major evolution of C++, to stay in sync with C++ evolution 20, now 23, and the plans for 26. All right. Well, I want to zoom out a little bit. What's next for Cpp2 and CppFront? Do you have like a roadmap? Is there going to be a 1. cp front do you have like a roadmap is there going to be a 1.0 release do you envision there to be something where this is not good for production

use or is it going to remain an experiment so it the license still i deliberately chose a license that does not allow uh forks or production use simply because it's it's an experiment like people shouldn't be trying those things it's hilar incomplete, as I mentioned in the talk last fall. And in the talk, I gave a little mini roadmap. I mean, 1.0, who knows if we'll even get there. That's so far down the road, I don't even contemplate it. But the roadmap that I showed in the fall was to work next on explicit template parameter lists. So I have implemented those. After that, to work on

types, being able to author types, not just functions. So I recently added namespaces. Type support was added about three weeks ago. Partly, it's still in progress. So now I'm working on four declarations to be able to let types refer to each other, order independently. So that should be coming, I hope, in the next couple of weeks, three weeks. So we're continuing to make progress there. Just added requires clauses a couple of nights ago on the weekend, which actually turned out to be really easy. And thanks, Philip, also for your help there and Joel and others. So we're getting there. In fact, my next steps will be, I'm getting close to where I have full support for classes. I just need to implement the order

independence and inheritance. And then I think I'm mostly done with classes and then work through the bug tail. Thanks for the bug reports to harden those initial implementations. And then I intend to start seeing about self-hosting CPP front and start writing parts of it because I can do a line at a time or a function at a time to try to write parts of the compiler itself in CPP2. It should be complete enough then. And maybe that's a time to reach out to two or three people super privately, just to say, hey, it's kind of ready for some people to try to write programs with, but stuff's

probably going to break all over the place. So it's going to require a lot of hand-holding and white-glove treatment. So maybe find two or three people that I'll be spending a lot of time with of my evenings and weekends fixing bugs for to start writing some real code and trying out a small project or two here and there, in addition to my own dogfooding trying to self-host. So that'll probably keep me busy for a lot of this year. That sounds actually quite interesting. It sounds like interesting work that's going to happen there. So looking forward to hearing about that. Who knows, maybe we'll get to an 0.1 release

sometime this year. So speaking about hearing about it, where can people learn about CPP2 and CPPFront? And is there anywhere that, you know, anybody can just go and try it out? Is it like on Compile Explorer or is that something on your GitHub where people can download it or check it out and start playing around with it? Well, it is on Compiler Explorer. In fact, Matt Godbolt put it up there, bless his heart, during my talk when we hadn't talked about this before then. So thank you, Austin, for asking and doing that. And my goodness, my mind is still blown about that. Thank you, Matt.

And so you can find it on Compiler Explorer. The GitHub repo is, GitHub is hsutter.cppfront. And you'll find basic information there. There is not documentation yet because it's not intended to be people trying to use it. But the best documentation is the main GitHub page, the readme there, and including the links to the talk. But I am going to give an update on it at C++ now in a little over a month from now. And so I'll give an interim status update there, including some of the things that have happened since the

CppCon talk. And then of course, CppCon, which is in the fall again this year, it's usually in September, but this time it's the first week in October, which gives me a whole extra week of coding. I plan to give an update again there with what we do in the next six months. But definitely C++ now is probably, I have a few more things to say there about what's been happening. But yeah, look at the repo and the CppCon talk. That's the main material right now for those who are interested. And thanks again, Matt, for putting it on godbolt.org. So we have a bit of a trend on this show where each episode seems to be running longer than the previous one.

So we're going to have to cut this short a bit. Could talk all day, of course. But is there anything else you want to tell us before we let go, Hub? I think we've covered the main thing. As far as things to look forward to in the C++ world itself, I think it's great that we're having these discussions about what would doing a major evolution

of C++ look like, and seeing many different complementary ideas along those lines to see what can be done and what's feasible and possible. I think it's great that we shipped C++23 on time despite a pandemic. And so thank you to the whole C++ Committee for all the work in switching to Zoom. And we've had literally hundreds, it's over 200 a year now, of Zoom meetings in the various subgroups. Like it's an enormous number to get to where we are,

to have a nice release of C++23. And now we're going to soon be starting on C++26 at the June meeting in Varna, Bulgaria, which will be just our third face-to-face meeting since 2020 when everything went sideways. So we're looking forward to that very much. And yes, the vibrancy and the health and investment of ideas and effort in the community is great to see. C++ is alive and well and thriving. How do we evolve it? How do we direct its evolution and get the best result for all C++ programmers, including us who use the language? And how do we deal with the safety

issues, which are getting more and more attention and rightly so, I think is going to be the and how do we deal with the safety issues which are getting more and more attention and rightly so i think is going to be our big challenge and i i see those discussions happening and i see good ideas happening there in progress so i look forward to seeing what comes of that in the coming year or two exciting times indeed thanks for being a part of that and thanks for being a part of this show as well being on as as our guest. Where could people reach you if they want to find out more? They can reach me in the GitHub repo, and they can also reach me at herb.sutter at Gmail, and hsutter at Microsoft. So that's the easiest way to reach me. All right, thank you. All right. So thank you so much, Herb, being on the show. Thank you for having me. It's been a pleasure. Thank you so much for listening in as we chat about C++. We'd love to hear what you think of

the podcast. Please let us know if you're discussing the stuff that you're interested in. Or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow CppCast on Twitter or Mastodon. You can also follow me at Timber underscore Audio on Twitter and Phil at Phil underscore Nash on Twitter or at Mastodon at philnash.me on Mastodon. And of course, you can find all of that info and the show notes on the podcast website at cppcast.com.

The theme music for this episode was provided by podcastthemes.com.