CppCast - Heterogeneous Computing and C++ Language Evolution

Episode Date: April 5, 2024

Erich Keane joins Timur and Phil. Erich chats about the recent WG21 meeting in Tokyo, his roles as chair and co-chair of the Language Evolution and Language Evolution Incubator working groups, respectively, as well as heterogeneous computing and his work at NVidia. News CppCon - Call for Speakers ACCU 2024 Online Bjarne Stroustrup responds to White House warning against C++ David Sankel's post on Boost split Links New C++ meetup in Vienna, Austria Tokyo ISO C++ Committee Trip Reports: In-depth status report Herb Sutter's report Think-Cell's trip report (Jonathan Müller) Papers discussed: P2900R6 - "Contracts for C++" P2996R2 - "Reflection for C++26" P2688R1 - "Pattern Matching: match Expression" P2830R1 - "Standardized Type Ordering"

Episode 379 of CppCast with guest Eric Keen, recorded 2nd of April 2024. This episode is sponsored by Sonar, the home of clean code. In this episode, we talk about a new C++ user group, the latest conference news, and recent events in the Boost community. Then we are joined by Eric Keen. Eric talks to us about the ISO C++ committee meeting that took place last month in Tokyo, Japan. Welcome to episode 379 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? I'm all right, Timo. How are you doing? I'm all right. I came back from Japan. We're going to talk about that later. I also mostly recovered from a really nasty lung infection that took me out of action for several weeks. Yeah, a lot of that going about. Which is part of the reason why we are a bit late with

this episode i think i'm going to talk about that in a minute but yeah i'm doing well and the other great news i you know i always talk about the weather here so the snow is actually almost completely gone finally we had a few days where the temperature was above zero so nice uh yeah that's great um it's getting warmer and not icy anymore, so I can go outside and resume my running and things like that. So that's great. Springtime. Yeah, that's good to hear. Clear out a few of the cold webs. Yeah, yeah. How are you doing? I've been busy, as usual, for reasons that we might get to perhaps in the next episode. I thought it'd be a bit too soon to talk about that but uh yeah so how our schedule seemed to have got um sort of out of control around the same time again so we did miss one episode i

managed to hold the fault for one but we are we are back now and we've actually been working on queuing up our pipeline uh we're put right up to the middle of may now i believe so yes and we have some really exciting guests for the next few episodes. Including this one. Yeah, so apologies from me as well. I mean, I have, I guess, a good excuse. I was really out of action for several weeks. I was just in bed.

And then immediately after that, there was the Tokyo committee meeting, which was so busy. Yeah, so just pretty much a month where I couldn't sit down and record an episode you did one without me so thanks for doing that it was great i watched i i listened to it um i really enjoyed it but yeah very much uh back on track now uh so you can expect an episode every two weeks again all right so at the top of every episode we like to read a piece of feedback this one is from robert shimkovich, who sent us an email and said, I'm enjoying your show and always learning something new. The lineup of guests in your last shows was really excellent. Please keep this up.

I have a little announcement if you're willing to share it. Of course we are. A new C++ user group is forming in Vienna, Austria. You can find us on Meetup, www.meetup.com slash cpp-usergroup-vienna. Our first meeting is on Tuesday, 14th of May at 6.30 p.m. Until we have a proper domain, you can also reach us via email or follow announcements on Mastodon. And we'll put the links to those in the show notes.

So thanks, Robert. It's always very exciting to see a new meetup group pop up. As I always say, local meetups are the backbone of the C++ community. Vienna is a lovely place. I've been fortunate enough to be there. So very good to see that there's a C++ meetup there. So if you are in Austria, in the Vienna area, please attend and meet other fellow C++ developers.

And Robert, I wish you all the best for your new meetup. Absolutely. And anybody else listening that's thinking of starting a meetup or about to start one, and I've said this before, but do let us know and we will announce it on the show. We do want to support our meetups, especially as I notice this particularly

going through some of our community partners on our conference sites recently. We have lots of partnerships with meetups, particularly around Europe, and realized that many of them haven't met since before the pandemic, and they're dead links now. So a lot of them did disappear.

So we need fresh blood in to start up new ones in their place, and we'll announce them here. Yeah, and both Phil and i actually do run meetups in our respective cities where we live so if you need advice on how to get started feel free to reach out and i i hope i speak for phil as well here we both will be very happy to help you out with advice or whatever else we can do all right so we'd like to hear your thoughts about the show you can always reach out to us on xmaster.linkedin or email us at feedback at cppcast.com. Joining us today is Eric Keen.

Eric is a principal compiler engineer working for NVIDIA on the HPC compiler team. He is also a code owner on the Clang project, owning the attributes and template implementations. Additionally, he's currently working on a front-end implementation of OpenACC, a parallel computing annotation language for Clang. Previously, he also architected and implemented the Clang version of C23's bitint feature. Finally, Eric is a member of the WG21 ISO C++ Standards Committee, acting as the co-chair for the Language Evolution Working

Group and as chair of the Language Evolution Incubator. Eric, welcome to the show. Hi, Timur. Thanks for having me. I'm a bit of a long-term listener, so it's nice to finally get a chance to meet up with you guys here. Long-term listener, first-time caller? Pretty much, right?

I tried to avoid that old saying, but I guess we can't avoid it even on fake radio or non-terrestrial radio. We can't miss an opportunity. So it's interesting. I heard you implemented bitint in Clang for C23. I didn't know too much about it, so I looked that up. And as I understand it, that's you specify the bitwidth of an integer representation. Is that right? That's exactly correct.

Right. It was while I was at Intel. We had, at the time, owned Altera, a FPGA company. And bits are really, really valuable on FPGAs to the point where you need a small value that eight bits to represent number 0 to 100 is too expensive. And they had been kicking around for a long time what they called an arbitrary precision integer type. And over three or four different implementations, we pushed to Clang extint,-t-int that did the same thing. And it's really, really handy.

It exposes a lot of what LLVM has, which is arbitrary integer sizes, all the way up to 1.9 million bits or something. Yeah, so it was really useful for FPGA. And then once we started publishing it, and I have a blog post that I did for the LVM community at one point. Once we published it, we ended up seeing a whole bunch of other use cases in a variety of businesses. And it's pretty incredible, the response we got to that. I was really excited by that. And then we published a proposal for C committee, the WG14 committee.

And they kind of ran with it. A bunch of them saw uses of it. And my understanding is we even have a GCC implementation of it now. It's, yeah, like I said, it was kind of a really rewarding feature to see take off as much as it did. Nice. Yeah. Well, I know a lot more about you now. Thank you. All right. So, Eric, we'll get more into your work in just a few minutes. But first, we have a couple of news articles to talk about. So feel free to comment on any of these, OK?

Sure. So the first one is that today the CppCon call for submissions got published. You have until 19th of May to submit your talk to CppCon. We aim to send accept-reject notifications by 23rd of June. The actual conference, CppCon, takes place this year, 15th to 20th September, again in Aurora, Colorado, at the Gaylord Rockies Resort. We again have a general program you can submit to, as well as a bunch of special tracks.

Back to basics, tooling, et cetera, a bunch of them, each with their own track chair. And one new thing this year, we actually also now have a game dev track, which is chaired by Guy Davidson, who is joining the CppCon team in that capacity. Another new thing this year is that I'm actually the program chair for this year at CppCon.

So I took over from Daisy Holman. So I'm in charge of the conference program this year is that I'm actually the program chair for this year at CppCon. So I took over from Daisy Holman. So I'm in charge of the conference program this year and of managing submissions and reviews and stuff like that. So you can blame me for that. The first thing that I actually did in that capacity is you'll notice the submission form looks different from last year. So what happened there is that for managing submissions and reviews we got rid of the previous system which was some kind of combination of easy chair if anybody knows that and like a bunch of like homegrown stuff and scripts and things like that and we migrated all of this to a new system called speakerfish which actually has been developed by phil and his company shaved yaks so phil do you want to mention uh talk about this briefly? Well, just very briefly.

Obviously, I originally built this for C++ on C, and since then a lot of conferences have taken it. It's been in sort of perpetual beta, but I'm starting to polish it a bit now, and it's now ready for use by CppCon. So if you are a regular speaker, and it looks familiar,

that might be why. Alright, so very excited to um work on cpp con this year and also attending it and having lots of awesome people speak there so please submit your talk another conference which is happening much sooner actually two weeks from now is accu uh in bristol uk which phil is also involved in do you want to talk about that briefly yeah i mean we talked about it before, so I'm not going to spend too long, but I just wanted to remind people,

since it is quite close, if you haven't got tickets yet, now's your chance. And to remind you that there's actually online tickets as well. It is a hybrid conference this year. I've had some feedback that that's not as obvious as it should be, so I thought it's worth mentioning again here. You're not able to make it to Bristol. Obviously, the best experience is going to be in person,

but we do strive to make the online experience good as well. Yeah, it's interesting that some conferences have chosen to retain the hybrid model, kind of, I guess, after the experiences we had with online conferences during the pandemic, and other conferences like CppCon, for example, went back to the old kind of in-personperson model phil where you are on that do you have any idea of like uh yeah well that's complicated but we uh we spun the online part out of c++ on c into its

own conference c++ and nine we talked about that before as well. I think that's actually run since we last had an episode. It actually went really well. We were really pleased with the number of people that we got, their engagement, and we got a lot of really good feedback that it went really well. We learned a lot as well. I think there is still a place for

a good online conference. So with ACCU, we are trying again with the hybrid model. That's a bit harder. So I'm not going to guarantee it's going to continue, but if you want to see it continue, then please buy tickets for this one so we can make it a success.

Right. Okay, so I'll be speaking at ACC as well about the latest state of the contracts proposal. So I hope to see many of you there. I have two more news items. One is actually something that we covered in the last episode, the one where I was away.

Thank you, Phil. The White House paper called Back to the Building Blocks, A Path Towards Secure and Measurable Software. President Biden's administration basically urges the world to move away from C and C++ and towards memory-safe languages such as Rust.

So this has generated quite a lot of discussion, which you've covered partially at the last episode. But what happened since then is that InfoWorld, which is one of those websites that like, you know, posting opinions on these things, they asked Bjarne Stroustrup, the creator of C++, for his take on this White House paper. And he replied with a rebuttal, kind of similar to how he published a rebuttal to the NSA report last year, which we're going to put a link into that article in the show notes. So he says the White House is obliv to incrementally improve guarantees although he does admit that the committee is working quite slowly on those due to the nature of the standardization process and he reiterates his claim that it is possible to achieve full type and resource safety in c++ which um it's a i think hotly debated claim we actually had him on the show at some point last year. Joke about that.

Yeah, I'm not sure there's any new information here, really, but I thought it was not worthy that Bjarne Stroustrup, you know, did like an official rebuttal of the White House paper. I'm not sure if any of you two have any opinions on all this stuff. Well, yeah, this is sort of a bell I've been ringing for a long time. I think the White House paper uses the correct information to come to the wrong conclusion. Switching languages is a little bit throwing the baby out with the bathwater, right? fooling around C and C++ and extensive experience that any company who has tried to switch languages of their main product will tell you is a horrible thing to do. You end up getting your old language written in your new language sort of thing.

I do think it's possible to write safe C and C++, but the papers from the White House is really an indictment on the community itself. We do a really bad job of pushing people to use the tools that are available. You know, from the very beginning, the existing package managers to find trusted libraries to do the common things. I think just about every time I see some level of huge internet affecting bug, it seems to be a lot of the times of spinning your own solution to something that exists. But more importantly,

and I think that things like the sanitizers and runtime static code, sorry, just static code analysis, compile time static code analysis, those sort of tools have the ability to enforce the safe subset of C++ that is not derived from what we inherited from C and the rules from the 60s that we can use to create incredibly safe C++ code. One of the sponsors of this, I think, is Sonar, right? They have a fantastic tool, and there's a number of other fantastic tools that do static code analysis that I think we had to attempt with the core guidelines, but that tried to kind of create another static code analysis tool that I thought was really well motivated. But I think as a community, we have to agree that some of these static code analysis tools are a necessary part

of our tool chain and run them. If you really care about safe code, you need to be running those. You need to be testing with the address and undefined behavior sanitizers. Those are really incredible tools that we really just need to start using. I think the criticism is not so much that those tools don't exist, but that there's nothing that enforces they use, right? And the way that Rust does it by default, for example. So like anybody could write a open source library, just not using any of those tools, right? Put it on GitHub and then somebody else can take that library and use it in some program that runs on critical infrastructure, you know? And I think that's kind of where the problem comes from. Like there's nothing enforcing these things.

Right. And you're absolutely right on that. But I feel like our way of enforcing that is akin to what MISRA attempts, which is to kind of make it a necessary part of the tool chain. It's more of a social problem, right? The idea that you write C++ and you don't run those sort of tools needs to be something that we sort of shun, right? You're not allowed to call yourself

a safe C++ programmer or C programmer unless you use those. And we need to be able to convince our management that those are the necessary tools we need to be using. And a lot of- If you're working in a startup and you're trying to release something as quickly as possible, then good luck convincing your manager of introducing more tools to the tool set.

Unless a startup is doing a self-driving car, perhaps. But actually, yeah, it's interesting you bring up MISRA. Well, it's also interesting you bring up static analysis, so I didn't have to. Thank you for that. But interesting you bring up MISRA because the new version of MISRA C++ 23 just came out recently. static analysis so i didn't have to thank you for that but interesting you bring up mizra because um i think the new version of mizra c++ uh 23 just came out recently i know we have talked about it before but one of the nice things about that is unlike the previous version i think it is something

that broadly speaking most people probably should be be using so not everyone will necessarily need to sign up for full mizra compliance but most of the rules are just generally good rules now a lot of them are drawn from the from the core guidelines and from other other things you know you'll end up writing good c++ if you follow mizra c++ 23 and there are tools that will that will uh will enforce that or at least guide you on it so that might be something to think about for the future. It is definitely a good starting ground. Some of the rules, at least historically,

have been a little onerous and made the language overly tough to use in ways that I didn't think were good ideas. But it is a great starting point. Most of the rules there are, like you said, fantastic ideas and just great ways to start programming. Yeah, they have managed to shed a lot of the historically the worst rules, like the one about single exit. That's no longer a requirement.

In fact, it does encourage early returns, whether that makes sense. Oh, interesting. I will have to look that one up. We could do a whole episode on that. In fact, we have done. All right. So we got one last news item to talk about before we get into the meat of this episode.

And that's about David Sankel, the Executive Director and Chairman of the Board of the Boost Foundation, who published an April Fool's post on boost.org. And we're going to put the link into the show notes so it's uh starts with hey all i have a few updates regarding boost organization and yeah it was released yesterday at the time of recording so on the first of april it has a bunch of stuff in there that's obviously a joke like boost is moving away from the mailing list and moving to discord and

they received a grant from mic to port Boost to Rust. And the Boost Foundation will be dissolving itself for popular requests from the Boost developers and things like that. But it also actually has a section in the beginning that is actually not a joke, but very serious. And I got permission from David to talk about this on the show. So the following part, which is kind of the first half paragraph of the post, according to David, is actually true. It says, first, as many of you are already aware, Vini Falco, René Rivera, and others from the

CyberSource Alliance have set up a rival Boost website, boost.io versus boost.org, Boost Twitter account, at Boost Libraries versus at Boost underscore libraries, and LinkedIn account. This behavior is gravely injurious to the Boost community and amounts to a hostile takeover attempt. So the post goes on to say that these individuals have been banned from the Boost mailing list and the library is removed from Boost. That part, according to the information I have, is not actually true. It's what David suggested should happen.

However, the Boost Foundation board has not actually made such a decision. So David is kind of mixing kind of a real issue with like some April Fool's stuff in the same post. He is aware that this may have been misleading. He says that it was an attempt at venting his frustration in artistic expression. He told us he's going to publish another post soon to clarify things. Whatever you think about this, I think it's clear that it is going to send shockwaves across the Boost community for some time to come. I really hope they will manage to find some kind of solution to this. Yeah, it is quite a serious thing, I think. It's a shame that a lot of people have written this off as just part of the April Fool's joke. So I think it's worth highlighting here that that part is actually true.

I agree. As an outsider to Boost, I've, is perhaps a strong term for what that was. It certainly, to me, as an outsider, seemed like an alternative or a potential replacement versus just a rival. The Twitter and LinkedIn accounts, I thought, were a bad idea. That does seem a way of trying to bypass the board. As far as what happens out of it, I really do hope that this is not a case where they throw the libraries out. I think things like Beast is a pretty fantastic library. That it would be a shame if it came down to full-on bans rather than course correction. But of course, you know, that's just a view from the outside. I have no decision-making abilities.

Yeah. I mean, I don't have any deep insight into this apart from having had like a short conversation with David about this earlier today, because I was like, wait, hang on a minute. Like, is this really a joke? And yeah, I mean, if, you know, the director of the Boost Foundation board says that this is a hostile takeover attempt, then yeah, it seems to be quite serious. Let's hope they'll figure it out. Yeah. All right.

And so, of course, one big thing, apart from all of the stuff that we talked about already that happened in the world of C++ since our last episode, is that we actually had a C++ committee meeting at the end of March in Tokyo, Japan. This is where I just came back from. And this is going to be actually the main topic of our episode today. So I didn't make it into a separate news item because that's kind of what we're going to be talking about for the next half an hour or so. There's a bunch of trip reports already that you know we're going to put in the show notes we had over 220 people attending which is almost as many as you got in uh prague uh which was the last pre pre-covid meeting roughly two-thirds of those

people are uh actually showed up in tokyo the rest was on zoom so it's now been possible uh to attend online which i think is great. But everybody has the time and money to go to Japan. We adopted several language and library changes for C++ 26. And there has been a lot of other work going on. So yeah, we invited Eric today, who is very deeply involved with the committee and what's happening there. In particular, the language design stuff, talk to us about it.

So, yeah, Eric. So you're the chair of the Language Evolution Incubator, but also the co-chair of the Evolution Working Group. First of all, what's the difference between the Evolution Working Group and the Incubator? What's that about? All right. So as a bit of history,

the committee started as just one big room, big by their terms. It was about 10 or 15 people as it started. And eventually there was a need to split up the knowledge of the actual wording and the ideas people. And so that split up the evolution group, which both groups then split into

library and language so evolution is sort of the original spinoff uh the evolution language evolution uh working group is the original spinoff uh and it is the one that really makes the decisions on what is uh ready to put into language. What's a good idea? You know, just basically it makes all of the decisions. And then, of course, there's the groups after it that make sure the wording says what the evolution group did is, or what the evolution group wants is well-reflected. However, about, oh, I want to say seven years or so ago, the group started growing massively, right? As you can see, we're at, what, 220 attendees for a group that was sort of organized around 20 to 30.

So that became pretty painful, right? The evolution group was getting flooded with a ton of papers all at once. And the historical pattern of people publishing a paper that isn't ready for acceptance, but is just an idea paper, right? Something they want to throw out there and get feedback on. Or for newer members who are not used to writing papers and want to get feedback in a less ornery room, a room that's a little lower stress. As Timur, I'm sure, has experienced the high stress

of presenting to Evolution. Yes, I have some of the whip marks on my back from having presented papers in Evolution, yes. Yeah, so the idea was to form a more friendly uh intro group right to kind of filter papers to ones that have already kind of had a first pass as to whether it was a good idea a first pass as to whether it's in good enough shape that if evolution loves it as it is it could could just be shipped. So J.F. Bastion, the current evolution chair, was our chair of the incubator initially. And yeah, so it's kind of a filter group.

We do our best to give reasonable feedback. And the difference is the feedback we give is instead of being a criticism of the paper or saying negative things about the paper, it's supposed to be taken as feedback for how your paper and presentation can improve. Any questions you get in the incubator are ones that we will probably be asking in evolution. And the main group will ask these questions. So your paper should know these. are ones that we will probably be asking in evolution, right? And in the main group, we'll ask these questions. So your paper should know these, right? If they came up, they're ones that people are going to be thinking about. So you should put them in your paper.

You should put them in your presentation. A handful of times, these questions result in maybe my paper isn't viable. And that's, you know, acceptable. And, you know, to most authors are really informative. Right. Some of the ideas that come up are great. For one, one example is Epochs came out a few years ago, pre-pandemic. So a lot of years ago. And it's a fantastic idea. I absolutely love the idea of of epochs i i think it is that was vittoria romero's paper right that's right vittoria yes uh i thought it was a fantastic

paper uh a fantastic idea at the high level but it has some obvious concerns around how templates are handled right templates are this weird thing that doesn't exist anywhere until you instantiate them. So how those rules are enforced were kind of a big gotcha. That was one of the big things that came out in that room that I thought was fantastic feedback. And unfortunately, it ended up causing the authors to give up on that paper. But at the same time, it gave some really great early feedback for a paper that probably wouldn't have been seen for more than another year in evolution so i think that answers the question yes yeah it was getting early good feedback without uh

so so you're chairing the incubator but you're also co-chairing the actual evolution working group that kind of makes the decisions about the language design so you're really the incubator, but you're also co-chairing the actual evolution working group that kind of makes the decisions about the language design. So you're really the person to talk to when you want to know what's happening in C++ language design right now. What's happening on the committee. I do get a great visibility into that being on both groups. I get a great mix of papers that are in the idea stage or in the still the development stage all the way to right before we hit language wording. So yeah, I'm really kind of excited about the position I'm in. I sort of fell into the evolution co-chair role. I was the incubator chair or assisting

with the incubator chair role pre-p pre pandemic. And then the pandemic shook up the amount of people who were able to contribute, um, mixed with the evolution chair moving halfway around the world to Tokyo. Our, uh, he was our host actually for this meeting. So I ended up hosting almost all of the telecons, uh, which was a pretty enlightening experience, a pretty fantastic experience. So at that point, I was fourth or fifth in line for the chair. But as the one who could do that, it sort of made me kind of an obvious person to be the co-chair of Evolution.

And I've had a fantastic experience helping out JF chairing Evolution. He's a fantastic chair who has done great things for the meeting, and I'm just proud that I can help him out with that. Great. I had a bit of a logistical question about that, though. Sure. Because I've not been long for a while, but as I remember it, the main Evolution groups and the incubator groups tend to meet at the same time. How can you be in both places at once? I can't. No, the incubator has really interesting discussions,

and we often try and schedule it at a time where there is a fairly polarizing, as far as interest, topic going on in evolution. So, you know, there are things where a good amount of the room probably doesn't care enough to comment or doesn't know enough to comment that the incubator is kind of a great place to come and give additional feedback. And beyond that, you don't have to be in all the rooms, right? A big part of how the committee works is that we trust that the other members of the committee are acting in good faith and doing a fantastic job. And of course, you know, we can count on that. So, you know, just because you're not in the room doesn't mean something bad is going to happen. So in general, I've had a great experience

being able to separate myself over to the incubator. Evolution has picked up another co-chair who has helped when I'm not there, who's Hana, who I think has been on here before. You really don't have to be everywhere all at once. You can kind of trust everyone. So you've been sharing all the telecons pretty much for a year or so before Tokyo, right? The Evolution ones. Yeah. So Evolution didn't host telecons once we started doing in-person again. Oh, okay. So there haven't really been any.

But this was all during the pandemic before whichever Kona was the first one that we came back we were hosting at least one every two or three weeks I think and so we got a lot of feedback on papers and we kept the committee moving which was really important to us right so coming to Tokyo itself then what's's your main takeaway from the meeting? What's the most interesting things that you saw in that week? Yeah, so Tokyo was really, really interesting to me. It really feels like our first back-to-normal in-person meeting. All of the groups have kind of finalized doing a great job at remote participation, which I think we've done a great job at making remote people first class members of the committee.

Which is really hard, by the way. Other than the timeframe being in the middle of the night for half the US, we were great at getting others to participate from overseas from the meeting who couldn't attend. As far as this kind of being the first big meeting it feels since we got back, a whole bunch of papers that I found really interesting along the way, kind of all hit their stride this meeting. So the big one, of course, and I don't know if any of this is spoilers for later, but reflection, we did a whole day on reflection, right? The reflection study group forwarded their proposal at the end of last meeting. So we did get a whole big introduction on reflection and it was really exciting to see that. Teamer presented contracts, which is another one with a interesting, rocky, fun history

that I think shows a lot of promise. And, you know, that proposal has come a long way. And so I'm really excited to see how we can do for that one and whether it'll make 26 and, and you know how quickly it can get to evolution level maturity so that we can approve it.

And then pattern matching is one that I've seen bounce around for maybe six or seven years now that has always been really, really interesting when it's come in and has always been that one little step away from, from being a complete idea or the right complete idea. I didn't get to see it because of the incubator this meeting. But my understanding is that there was actually a very mature proposal. And so I'm really excited to see that. So yeah, in general, the Tokyo meeting, I thought was a fantastic step forward and our first big step since probably concepts got merged after its split of the syntax

from the, of the Terse syntax. So yeah, like I said, I feel like I'm really excited about the future of C++ 26. Great. Since you mentioned contracts here, and we have TMI here, is that worth digging into a little bit more about what actually happened? Well, we spent a whole day on that as well. I presented the proposal that we've been working on in SG21 for like the last five years while having a really bad cold and cough and like having lost my voice so that was

a bit challenging but I think it was good because we saw where there was like work to do where evolution doesn't quite agree on like the conclusions we had in SG21 it's kind of crystallizes like in very particular spots where we kind of already knew that, yeah, there are people who are going to disagree with that. There's going to be more work to do here to reach consensus. Things like storing violation handlers. Should a violation be allowed to throw?

Or should you be able to... What was the other one? Should you be able to turn off contact checking at compile time or turn off contact checking at all? Things like that. So there's a handful of these items that we kind of have consensus on in SG21, but that's not helping us if Evolution doesn't agree. So we need to find a way.

And yeah, that's what we're going to be working on. SG21 will have telecons every week now, I think, until the next meeting, St. Louis, which is going to be working on. SG21 will have telecons every week. Now, I think until the next meeting, St. Louis, which is going to be in June. And we're going to try and figure this out together with you, hopefully, somehow to reach consensus. Great. So, throw showstoppers in. I didn't see

any showstoppers. There was definitely a lot of feedback given. SG21 has a pretty full plate of work to do based on the feedback, as I'm sure Teamer will agree. I think the core idea that Evolution really liked in the C++20 cycle is still there. And I think the proposal, as Teamer presented, is a vast improvement over what we were going to put in C++20. I think that this break between 20 and 26 and this effort has shown a lot of progress. So I'm really excited to see if we can get this in 26.

There's a lot of really good stuff. A lot of questions we have, parts of the painting that need to be filled in maybe. But in general, it's a feature I'm really excited about. That's great to hear. I think the things that we have to work on are not so much things where like, oh, we don't know how to do this. That's not really anything like that. It's more like, how do you want to use contracts?

What are they? And what's your use case for them? And depending on that, you might want to do this or that. And then sometimes those things are mutually exclusive and you kind of have to pick one. And that's kind of tricky. So, yeah. Yeah, there's a ton of really hard decisions

that need to be made is the problem right and sg21 has been off on its own for like teamer said five years so the reading of the room of the things that evolution didn't really care about or the things that evolution really cared about i think are fantastic feedback and are you know for people in SG21, if they want to continue insisting on what evolution disagrees with, at least it'll be known that that's not fruitful. And then how to concentrate on the things that evolution does really care about and how to make those really important.

Fix those and get those to the point where we can release. Yeah, I hope that at St. Louis we can really focus on the contentious points and drill down into those a bit more and have proper presentations on those things. But yeah, I mean, I think reflection is probably the one paper that I would say is more significant than contracts for the overall language,

even though it's hard for me to admit that. I've been working on contracts for a long time, even though it's hard for me to admit that, that I've been working on contracts for a long time. But I do think that reflection will have an even bigger impact. So what's your takeaway on that? Are we close to having reflection in the language or forwarding it to the wording groups? Or are there still big open questions there?

How far are we away from actually putting it into the MSF 26 working draft? That one I do think is closer. It is a really mature proposal that's pretty close. There were definitely a list of criticisms that I would really like to have fixed. Like using the character is unfortunately something that Klein can't live with.

It's a shame. It's a beautiful operator. I like it. It's like the clash with the Objective-C blocks or whatever, right? Yeah. So there's a little bit of clash there, and I know there was some people saying that it doesn't

completely clash with Objective-C and Objective-C++, but... I think you can still parse it unambiguously which one it is. So I'm not quite sure what the problem is, but you probably know that much better than I do. Yeah, it's just as much that

from the Clang code ownership perspective, we see the carrot as completely belonging to Objective-C. They own that character and what to do with it. It is effectively their extension point. And so if Objective C++ came out with a proposal in a few years to do something that conflicted, you know, we don't want to block their design space. And while it is nice that is a single token, a single character token, I don't think it is a particularly useful for reflection character. It doesn't speak to me as saying

reflection, so I think that some level of bike shedding as to a character could come up with something at least equally as good. Well, I thought the carrot means that you lift the entity into the meta version. That was what David said, wasn't it?

Yeah, but to lower is square brackets around it, so it'd be different if it was the letter V for that. Yeah, maybe. I don't know, that felt a little contrived, the lift and whatever. I think that there's other

things in the solution space. I'm a little concerned about using a single character for something that is what I would hope is a fairly finite list that I'd be okay with something a little more verbose. To be more clear to read is the other thing, right? Like I want something that a newbie is going to find no problem kind of seeing what is going on, or at least having something to Google. Like, have you ever tried Googling what does carrot do in C or C++, it's like, it's a hard thing to Google. So I like the idea of a keyword of something like Reflexper, but I definitely understand that maybe that's a little too verbose for some. But I love that one's ability to be searched. And then I think the penalty paid is mostly by the handful of library authors that are going to write the things that the rest of us all really want to use.

Right. So Google tells me that Carrot is used in C and C++ for the exclusive OR operator. Yeah, but you knew the word Carrot, right? That's the other thing I... But Tim is saying it's already used, but I think you mean it's on its own? Yeah, not as a unary operator.

Not as a unary operator, only as a binary operator, yeah. Right. Okay, yeah, I admit it is hard to Google, I guess, yeah. Well, I guess we're going to have delightful debates about this over the next year or so, and I'm looking forward to that. Yeah, yeah, good to reflect on. Yeah.

Do you have any visibility on, like, other stuff that's going on in the committee? I think there are maybe a couple of hot topics on the library side as well, like the whole like execution, sender, receiver stuff. I don't know. Like I'm also, because I've been focused on like one topic for like quite a while now that I also, I don't really have this like overview anymore about like all the other relevant stuff that's going on. Do you have the same problem or i really do uh before i got into being a compiler

engineer i was really into library stuff um in fact my first c++ meeting i attended the library wording group uh and i don't get enough visibility there that i really wish i had the i know these senders receivers and executors stuff is really important for parallelism but i have other people who work with me who are doing a fantastic job paying attention and developing that so between being a compiler engineer and being kind of exclusively evolution side, I'm unfortunately very language based. I do get a little bit of visibility into some of the problems they have with the language as things come up. So, you know, the incubator got a couple of really interesting papers, which I can talk to either now or a little later, that were kind of all about supporting executors and senders receivers interesting

um i would love to drill into that but we're like maybe we should move on because we have yeah we have we have uh like 15 minutes left or something so might have to make this episode a two-parter. Phil, do you want to tell us about our sponsor today? Yeah, so we are sponsored once again by Sona, the home of clean code. Sona Lint is a free plugin for your IDE, helps you to find and fix bugs and security issues from the moment you start writing code. They help you to write safe code as well.

You can also add sonar cube or sonar cloud to extend your cicd pipeline and enable your whole team to deliver clean code consistently and efficiently on every check-in or pull request sonar cloud is completely free for open source projects and integrates with all the main cloud devops platforms so talked a lot about what's going on inside the the committee but I presume you have a life outside the committee as well. We mentioned you work at NVIDIA. Is that a thing? Is that something that exists? I don't know anymore. We'll find out.

So you work at NVIDIA on the HPC compiler team. So what is that? Yeah, so HPC is high performance computing. NVIDIA has a handful of compilers. The one most of the people on my team work on is NVC++, targeted HPC machines. They have a fantastic, mature compiler that does a lot of really, really good offloading for devices. So I hate to call them graphics cards because they're not really that anymore. But for lack of a better term.

Massively parallel processes or something. Yeah, I'm really excited and was really excited to join this team because of how much interesting work they're doing on normalizing parallel computing and getting massive parallel computing to be a thing that the rest of us can use. Right. That's interesting. That's all around dedicated hardware and compilers now. I did HPC some years ago now at a bank, and it was more

about putting PCs on a grid and distributing computations across there. But I think there's definitely an opportunity even back then to go heterogeneous. So that's what it is, all about taking advantage of the NVIDIA silicon for that. Yeah, absolutely. Heterogeneous computing, I think, has a great future to improve the performance of all of the things we've been trying to do for years. You know, having stuff no longer be processor bound is kind of going to be a great addition. Yeah, no, that's great. I mean, I got into programming, like the first thing where I was actually writing code was I was doing astrophysics like way back and we did these simulations and we thought that

was HPC. But you know, that's, that was all just on the CPU. It was like Fortran and then later C and then eventually I discovered C++ as well. But, and it was,

yeah, just normal code that runs on your CPU crunches numbers. And then you parallelize that with like Openmp and mpi and just run that on like 300 cpus at the same time somewhere in a cluster and that's that's pretty much it like there wasn't any dedicated hardware or anything like that um so it's kind of really interesting to see how far how far we got along well or maybe maybe it existed back then but just not in that science astrophysics space like you did a really good description of kind of what we're doing today right the running on a ton of machines the difference is each machine also has the ability to split off hundreds and hundreds of processes for for graphics hardware. Something like astrophysics is a lot of

independent compute tasks that are really easily paralyzable that I think is probably I have no real exposure to it, but it's something that could probably be mass paralyzed

today to orders of magnitude better than you were able to experience back then i mean i'm sure i mean i suspect that they actually do this stuff today with like dedicated hardware and gpus and all that it's just i haven't been following this like i've not done any any physics academia stuff since i left 12 years ago so i haven't really kept up with what they're doing these days but i i'm pretty sure they're doing things in a more efficient way and more interesting way than they did back then. Yeah.

And NVIDIA is kind of leading the way on pushing heterogeneous computing. CUDA is, I don't know, decades old now, it feels, is incredibly powerful. It gives you so much access to how offloading works that I was really excited for that. Another one, because you mentioned OpenMP, which also can do offload. So that's still a thing that was really big back then. Yeah, yeah. And in fact, they've got a lot of extensions to the language

or not extensions to the language. Improvements to the OpenMP language to allow for targeting devices. But we also have OpenACC, which I mentioned and I'll give a little plug to, that I'm working on a Clang implementation for

is a fairly simplified version of OpenMP that I think takes the really powerful parts and is targeted exclusively at offloading to devices. So it does a fantastic job at allowing you to describe your situation. It's a little more descriptive than proscriptive, right? You describe what's going on and it gives the little more descriptive than proscriptive right you describe what's going on and it gives the compiler more power to optimize so yeah it's uh it is another alternative to that it is a really interesting and and growing uh environment for development so that's uh that's

at nvidia but before that you were at intel doing compiler stuff as well. So what was the difference there? Is that more CPU bound? So I've still always been a front-end engineer, and the front-end is everything pre-optimization. While I was at Intel, I was architecting

the front-end. We did a switch over to be Clang-based over at Intel, and I led that effort. And then as we, you know, over the last few years, Intel got big into Sickle, which is another heterogeneous computing language. And so I was heavily involved in that as well.

So yeah, I mean, a lot of it is language enforcement that we do in the front end and adding the new features like contracts or reflection, hopefully someday. So I did a lot more of that. And we'll be doing that again soon. Right, right. That's really cool. So I want to get back to something else that your bio says. It says that you're a code owner on the Clang project, which I assume you're very active there.

And you actually own the attributes and the template implementations. I actually thought that Aaron Bauman was doing that. Did you take over? Did something change there? Yeah. So a few years ago, Clang development sort of stagnated. There were some

big companies that weren't putting as much investment in and our maintainer at companies that weren't putting as much investment in and our maintainer at the time was not contributing as much as he used to. So Aaron's kind of stepped up to lead ownership of Clang, which we're very grateful for. But it's also a massive job

owning all of Clang. So he split up code ownership into, I want to say, six or seven pieces. And one of them was one that had already been split off was attributes, which he kind of handed off to me. We're still kind of a two in a box on that for the most part. He does a lot of the attributes review and work as well. Templates he kicked off and I picked that up. So yeah, Aaron was doing it. I'm kind of transitioning to do it as well.

Aaron and I kind of speak on a near hourly basis during the workday about stuff like that. So it's a much more productive ownership team now that does a lot of code reviews to enable more development. Well, it sounds like the Clang project is in good hands. That's really cool. Yeah, I'm really excited about the direction it's going.

But what does it actually mean to be a code owner? I mean, do you get to do all the implementation or you just oversee it? It's mostly overseeing. It's a little of all of those. Life's way too short. Days are too short to do all the implementation. So as much as the previous code owner tried to do all of the implementation and was actually super effective at it,

we've been concentrating on doing code reviewing and enabling new developers as much as possible and growing the client community. So code ownership is very much doing code reviews, helping triage bugs figure out what bugs are applicable, and in the end, making the decision on what features we want, what are good ideas, what is the right way to implement things. So it's a maintainership role that we're doing our best to concentrate on enabling new engineers to join. And we've been incredibly successful at that.

And I hope continue to be successful at improving contributions by both quantity and quality. And so I guess you get to work on that as part of your daytime job, right? So NVIDIA basically pays you to contribute to Clang. They do. I was really happy that I was able to continue finding a place to work that also very much enables my Clang contributions.

It is a big part of the health of the language to have as many implementations as we do. So keeping Clang healthy is very important. All right. Well, I think we're getting to the point. So we need to start wrapping up. Is there anything else in the world of C++ right now that we haven't already talked about? I know we've talked about a lot of different things. Anything else that you find particularly exciting

or interesting? Let's see. I really do think the push toward heterogeneous computing in a number of different applications are really exciting. I think that they're great extensions to the language that are going to improve compute everywhere. As far as the language itself,

I think there's a ton of really great little papers along the way that I got to see. One that I didn't realize was something I cared as much about is a paper P2830, which is a standardized type ordering

of types. Oh, that's Gasper's paper, isn't it? It is. Nate and Gasper. Nate and Gasper, yeah, yeah, yeah. Yeah, I remember he mentioned that on the BSI meeting. That's the UK National Biden. He discussed kind of people's paper drafts there

and things like that. He made a presentation about that one. That was really interesting. Yeah, he brought that to, I think, our previous meeting for his R0, and we gave him a ton of feedback. And I think he's gone a really good direction with the paper. And I think it's one of these papers that seems tiny, is probably pretty sizable to implement, but I think has some great implications and allows you to do stuff that is impossible in the language today.

So what is that about then? Yeah, so the main motivation is it's not uncommon to have a template that takes a number of template arguments, where you care about them individually, but not the order. So comparing those types becomes impossible right because you have no way of telling like do i have all the same template arguments as this other one and then when it comes to instantiating those types they get really expensive because you effectively have the cartesian product of all of these types and the longer that list gets the uglier it gets and there's a whole bunch of uh like ranges

stuff where it computes all of these things and the order is irrelevant but you know we have to keep it around so i i think there's a number of libraries and i think senders receivers is going to depend a lot on this where you can have your base, your top-level template that just immediately inherits from a class template that ignores the ordering or that canonicalizes the ordering. So your compile times are going to go way down. You now have way less overloads because you don't have to handle every version of the Cartesian product.

You only have the one that you really care about. So I find it really exciting, just the opportunities it's going to provide for writing cleaner template code. You have me at compile times go down. Yeah, yeah, we're going to see huge improvements when people start using it and as they can use it. And he's doing it at the right level, I think, which is to just provide an ordering. It's not a sort function. It is a function you can use, or it is

a capability you can use to implement sort, which is really powerful and has a whole lot of other implications that I can't even think about that I think are really going to help libraries do some really fun stuff all right nice all right so let's hope this paper goes in yeah um we gotta put a link to

this paper and all the other stuff that you discussed in the show notes sure so we are kind of uh at the time where we would wrap up so i just just want to say again, thank you so much, Eric, for coming on the show, being our guest today. I really love how we, you wanted to talk about Tokyo meeting, but then you also ended up talking about like Clang and lots of other interesting stuff.

So it was a great episode. Thank you again so much for being here with us. Is there, before we let you go, is there anything else you want to tell us? For example, how people can reach you or anything like that? Yeah. Well, first of all, thanks for having me. I've had a lot of fun here today.

The best way to get in touch with me is kind of through GitHub. It's just my full name is my GitHub, preferably in terms of a pull request against Clang. But, you know, we can only hope. Yeah, so people can feel free to reach out to me. I think my email address is available through committee stuff for committee papers. I respond as much as I can

to anyone who has questions for that stuff. So that's just my first initial, my last name at nvidia.com. Okay. All right, we'll put the GitHub account in the show at nvidia.com. Okay. All right. We'll put the GitHub account in the show notes as well. Yeah. But thank you again for coming on.

Yeah. Thank you. Thanks 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 we're discussing the stuff you're interested in, or if you have a suggestion for a guest or 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 and Phil individually on Twitter or Mastodon. All those links, as well as the show notes, can be found on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.