CppCast - Issaquah trip report and how the C++ sausage is made

Episode Date: February 17, 2023

Nina Ranns joins Timur and Phil. After community news, including conferences, a new C++ community in Africa and a new project manager and build system, we talk to Nina about the recent ISO committee meeting in Issaquah where the technical work on C++23 was finalised, as well as an inside look at how the committee works and Nina's current project: allocator-friendly library types that don't allocate. News Core C++ (cfp open) CppIndia cfp C++ Now - call for volunteers C++ on Sea (speakers and tickets) C++ Africa Zork++ 0.5 Links Orsen Scott Card's Beekeeper Analogy P2806R0 - "Do Expressions" Nina's user type categories talk P2644R1 - "Final Fix of Broken Range‐based for Loop" P2047R1 - "An allocator aware optional type" Embracing Modern C++ Safely P2674R1 - "A trait for implicit lifetime types"

Episode 354 of CppCast with guest Nina Ranz, recorded 15th of February 2023. This episode is sponsored by JetBrains and Sonar. JetBrains has a range of C++ IDEs to help you avoid the typical pitfalls and headaches that are often associated with coding in C++. Sonar Lint in your IDE helps you find and fix bugs and security issues from the moment you start writing code. In this episode, we discuss various news from the C++ community, a new C++ build system, then we are joined by committee member Nina Ranz.

Nina tells us about the C++ committee meeting that took place last week in Issaquah, and much more. Welcome to episode 354 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dubner, joined by my co-host, Phil Nash. Phil, how are you doing today? Yeah, I'm pretty good. Thanks, Timo. I just got back from yet more traveling, but this time it was for personal reasons, a little bit more relaxing, so feeling in a better place, I think. How about yourself? Yeah, I'm good. I also came back from the committee meeting, actually, in Issaquah a few days ago. And also, as of yesterday, I have internet at my new place here in Finland, so I'm not anymore tethering my phone, but I have

proper fiber broadband, so let's see how that's going to go. Yeah, good luck. Things are coming back together over here, slowly but surely. Alright, at the top of every episode, I'd like to read a piece of feedback. This one is a tweet by Conor Hoekstra, which he tweeted just before we released the last episode.

And Conor was saying, I love it when I realize on Thursday night that tomorrow is Friday, specifically the every other Friday where a CPPcast episode drops. Well, that's always good to hear. Well, except for that other Thursday, of course. 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 bpcast.com. Joining us today is Nina Ranz. Nina attended a committee meeting in the UK 10 years ago as an observer. She was curious to see how the committee works. On the third day, she sat in with Core and they were kind enough to let her sprinkle a few commas and wording at hand.

And from that moment on, she was hooked. These days, she is the committee secretary and one of the directors of the C++ Foundation. Throughout her career, she has worked for Siemens, Motorola, Datasift, and Symantec on everything from parts of the EMTS network to cloud-based antivirus products. She's currently working on allocator-friendly library types. Nina, welcome to the show. Hello, it's nice to be here. So what I got from that bio read was that you attended your first committee meeting and then you slipped into a comma.

No, but they do call me the comma girl. I'm responsible for the commas in the standard. Right, we'll have to bring that to a full stop. All right, we'll get more into Nina and the committee in a few minutes, but we'll have a couple of news articles to talk about, so feel free to comment on any of those, okay? So the biggest news, obviously, is that technical work on C++23 is now done. The committee has finalized its work on C++23 last week in Issaquah.

There's a big trip report on Reddit, which lists everything that happened last week. So we'll get more into all of that later. But there's also a few other news. There's some news from conferences. The first one is Core C++. It's a conference that's taking place this year in Tel Aviv, Israel from the 5th to the 7th of June, 2023. And they just published their call for papers. The submission deadline is 1st of March. So it's less than two weeks from now. So you want to go to Israel, submit your talk at corecpp.org. The next conference that just released their call for papers is CPP India.

It's a virtual conference taking place on the 5th of August, 23. I think it's a pretty new one. Phil, do you know if it's like the first one or they had one before? I think they had one before, didn't they? Yeah, I believe they did. I don't know if they've been talking about it for a while, so I may be misremembering that. But I wanted to try and attend this year, but unfortunately I'm actually on vacation again that time.

Well, it's virtual, so you could presumably give a talk from vacation, but that's probably not what you want to do. Actually, I just remembered that, yes, they definitely had a previous edition because one of our previous guests, Honey, she did a talk there a couple of years ago. Yes, of course. Right. So then more conference news. C++ Now, that's the conference in Aspen, Colorado, which is happening 7th to 12th of May.

Their call for papers is already closed, but they opened the general registration and they're also now accepting student and volunteer applications. So that's great because then you get to go, I think for free, they, I think, sponsor then accommodation and travel. If you're willing to work there as a volunteer, which is a great way of getting into that conference if you can't quite afford the steep price to get there. Pretty good deal. Yeah. One of the more expensive ones to get to and stay at. Yeah, and they're also not sponsoring speakers. I think if you're a speaker, you also need to pay.

So a good way to get around that is to volunteer. And then we have one more conference, don't we, Phil? We do, yeah. So C++ on C. We've obviously mentioned a few times before. By the time this airs, it's not quite done yet we should have announced our list of speakers uh shortly followed by the full schedule um and at that point we'll also make all the the standard price tickets available so early bird will close so when you're hearing this it will already be too late unfortunately but not too late to buy tickets.

So we'll put that link in the show notes with all the others. Do you want to remind us where and when that conference takes place? I could, yes. So that's going to be next June, end of June. I don't have the dates off the top of my head, but it is that final week in June. And that's going to be in Folkestone, England, of course, as it has been in previous years. I just looked it up. It's 28th until 30th of June.

You know more about my conference than I do. All right. Yeah, and I'm actually, I just got a talk accepted there, so I'll be there myself. And I think there's a good chance a few other people from JetBrains, which is my employer, will also come along. Okay, well, there's not just conferences. There's other community stuff happening as well. And one news item, which I found particularly exciting,

is C++ Africa. It's the official community of C++ developers from around Africa. And they started really recently, but they've already been quite active on Twitter. They also have a brand new Discord server. I've only seen this morning that it exists. So they're kind of just booting up now and getting some traction behind that. And that's pretty cool.

They're not just an online community also. They also have plans to organize in-person events in the future, but I don't think there's anything concrete yet at that point, but it sounds certainly exciting. Currently, they're already representing eight countries currently in Africa. Nigeria, Ghana, Cameroon, Kenya, South Africa, Liberia, Rwanda, and South America. And hopefully that's going to be expanding even more. So that's really cool to see like a C++ community movement coming from the African continent.

No, this is huge. Yeah, it's a huge continent, isn't it? Yeah. Huge continent that's particularly unrepresented in our tech community, especially in C++. So this is really great to see happening. Well, I bumped into a couple of people from Africa who were giving talks at conferences, but yeah, certainly doesn't happen very often around here in Europe anyway. So hopefully you're going to have more participation

and hopefully also more stuff coming from there. They're looking for support from other C++ communities. They're asking everybody to spread the word about C++ Africa and the fact that they exist, which we are now doing. They would also love to be involved in larger C++ related projects in areas such as finance, embedded and system engineering.

So you can reach out to them on Twitter at CppAfrica and also by email info at CppAfrica.org. And yeah, they're working on a website, I think, which is not up yet, but hopefully will be soon. Probably we should invite somebody from there on the show. What do you think, Phil? Oh, absolutely, yeah. It sounds like we may have a steady stream of invite somebody from there on the show. What do you think, Phil? Oh, absolutely, yeah. Yeah, it sounds like we may have a steady stream of people coming from there.

So we'll see what we can get in the pipeline soon. All right. Well, and then I have one more news item for you. It's something I saw on Reddit today. Zork++. I'm curious if any of you have heard about this not me it was first announced uh two months ago i missed it actually when it was announced but uh today i saw an announcement that they're now at version 0.5 zork plus plus is a modern c++ project manager

and build system for modern c++ which according to the authors uh was written because they needed to compile c++ projects with modules, C++ 20 modules, and no existing build system really supports that very well. So I think we covered last time that CMake is getting there, but at the time when they started this project, there wasn't really much available. So they basically wrote their own new build system for C++.

So we now have a new build system. Ironically, Zorg++ itself is actually written completely in Rust. So that's funny. The config files, I had a brief look at how it works. The config files also look very much like Rust syntax, like what you're writing when you write a project in Zorg++. There's also a very powerful command line interface. It supports all three major compilers, MSVC, GDC, Clang.

So I haven't had a chance to play around with it hands-on yet, but yeah, it looks exciting. So we have too many build systems in C++ already, so the solution is obviously to create one more. But this does look interesting, and we still haven't really solved the problem, so interesting to see another contender in the game yeah um i think we should probably do some episodes about build systems and related things in the future as well what do you think phil plenty of fodder there so yeah

we should we should reach out to someone if uh somebody wants to come on the show talk about zooka plus plus let us know all right so uh we have one more follow-up item from last time. So last time we interviewed Mike Dorm, and he shared with us the beekeeper analogy, and that seems to have generated quite a lot of interest. So on the show last time, we were not quite sure where this metaphor actually comes from, but then we got several messages from different listeners about that.

So we got an email from somebody saying that there was an article about the Beekeeper model from 2007 by James Dixon, which is kind of specific to commercial open source. So I'm not sure if that's exactly what Mike was referring to. But then there's also some writings by Ariel Weinswaig that sound quite closer to what Mike was talking about. And then more recently, we got a message on Mastodon. Somebody saying that actually this was written by Orson Scott Card back in 1995. And can't find the original text, but it's mentioned in other sources. There was an article called How Software Companies Die, which mentioned the beekeeper analogy. So still not quite clear where the original sources, but yes, definitely different sources kind of scattered around the internet.

And quite a few people really liked that analogy. I also really liked it, actually. Yeah, what I got from this was that bees and beekeepers are a great source of useful analogies in general. Yeah, I guess they are. So thanks to the hive mind for that one all right um so yeah we can um start our interview with nina hello nina how are you doing hello um i'm good thank you recovering slightly from the jet lag but otherwise very good yeah we're in the same boat here how many hours of uh jet lag do you have you had eight hours aren't you i have no idea you

know whenever we do these u.s trips i completely lose track of time yeah yeah for me it's not 10 hours because i'm two hours further east now in finland and i'll trust you whatever whatever you have minus one hour it's it's a lot i think it's minus two hours actually i'm two hours ahead of london now you're in the uk aren't you i am yes and it's half past one at the moment all right yeah it's half past three right here yeah all right so um yeah we had a committee meeting uh last week in issaquah it was pretty intense um lots of people were there some people online some people in person a lot of stuff happened there. Actually, there is now a summary on Reddit about everything that happened there.

It's quite a long list. But yeah, I mean, I have only obviously been to a very small fraction of those meetings that happened during that week. And I guess the same for you, Nina. Yes. But is there anything in particular that uh is kind of your favorite thing that happened there or something you'd like to talk about oh well c++ 23 obviously that's that's the big one and the concurrency ts but um it's it's it's difficult to pick your

favorite thing on a committee usually so many things happen um i think contracts made some good progress last week um i was i was i don't know you were probably there too in in cologne in 2019 when we pulled contracts from the yep i was there i'll never forget that so uh to see that we're making progress is always a good thing. So that was nice to see. I don't know. I think another interesting thing that's probably not a big thing, but I thought it was kind of cute and curious, is Duo Expressions proposal by Barry Revson.

Oh, I missed that. What was that about? That was, you know, interestingly, they came up with a proposal, I think on Thursday at the bar. The best proposal of the week. During some discussions, and I think he wrote it in something like half a day. I don't know. This is all just gossip. But yeah, do expressions.

It's an idea to add something in between blocks and functions to help with pattern matching. Well, not just with pattern matching, but it's a way of providing a set of expressions that have a return type that can be deduced from these do yield. That's what they call them at the moment, expressions. That would serve in this. It would plug a hole that we have at the moment,

which is when you invoke a function, you pretty much change the scope of execution. You can't break from it as easily as you can from a block. But then if you just have a block of expressions, you don't have a return type. More like a formalized, immediately invoked lander expression but without changing the scope yes a bit like that you don't have parameters to it um it's just a set of expressions but you can you can still deduce the type of the do expression by just looking at these well at

the moment they're called do yield expressions um do yield statements so does that mean that c++ is now going to be an expression language where like everything can be an expression or are we not quite there yet you know like can i can i put like an if statement into into a do expression yes you can you can you can you can put anything in a do expression um the idea is that you're still within the scope of where the do expression is declared i suppose um so you can like if you're in a in a loop and then you put a do expression inside a loop you can break from the loop um if you put a return inside your do expression then you exit the function that do expression appears in so it's it's like i said it's something in between a block and a function in the sense that it has

a return type but it isn't it doesn't doesn't change your scope you're still within the so it's not like a lambda it doesn't have captures, it doesn't use a scope. No, no. But it is kind of like a function object that has a return type. Yes. But you can...

So is it... Unlike, you know, lambdas have capture, but you don't capture anything. You can just refer to everything that's within the scope of a... outside of the do expression scope, like within...

If you declare your do expression within a function, then everything that's within a function scope, you can see it inside a do expression within a function, then everything that's within a function scope, you can see it inside a do expression. And it's very useful in pattern matching because at the moment for pattern matching, all the expressions have a return type void.

You can't change the return type there. So this kind of allows you to specify what your return type for each um for each pattern is that's really cool because for a moment i was thinking it sounds like it's a bit like syntactic sugar on top of go-tos but actually i realized no because they do have a return type so it's actually that's really cool yeah i've totally missed that. It's just a new thing. As usual, you don't always, every time we discuss a proposal and we kind of, we don't always accept it and put it into the paper. Sometimes we say, you know, we encourage this proposal to make more progress.

Go away and, you know, put in this feedback that we give you. Do more work. Do more work do more work come back um there was quite a lot of interest for that but you know it's again quite a lot of new keywords and right but that's what c++ 26 right because c++ 23 has oh yes yes yes this this is a new feature all right cool because i wasn't really um paying attention too much to the like the very new stuff i was pretty much involved in all of these things that kind of our last minute fixes for c++ 23 you know we fixed if

const expert this is something that i had a look at um sorry static assert yes that was the one we fixed static assert like static assert false like even if it's in a branch that you don't take like it would take your code down it would say it's reformed branch that you don't take, like it would take your code down. It would say it's reformed. And now you finally fixed that. I was obviously involved in fixing the thing about attributes. We now finally say what attributes actually are and what it means for them to be ignored. This is something I spent quite a lot of time on.

And yeah, there was all these other little things, like just like little last minute fixes. But like, it's good to know that there's already, you know, new feature development going on for c++ 26 and i guess the other thing i was also part of was contracts obviously because i was chairing it but i remember you were in the room i think we made some good progress there it was good to see people agreeing yeah we had like quite a few years on nobody agreeing on anything and now we actually did agree on something yeah i think that's the most difficult thing about standardization you know everyone everyone always thinks oh it's easy everything's easy we all know what contracts are but then again

different people have different perspectives and different views on what the right answer is but i guess i guess kind of part of the job is to like make sense of all these papers flying around and figuring out, okay, what is it that we actually need to figure out? Like what, what is the design space? Okay.

You know, whether a contract is evaluated. Okay. We need to figure out like this aspect of it. And then this aspect of it. And then, you know, we can focus the discussion a bit more and it feels like,

um, yeah, we actually made some progress there. All right. Well, anything else, um, from Issaquah that anybody wants to talk about? Oh, that was so much.

Yeah, that was so much. You sort of get overwhelmed after a while. You were in CORE as well, right? I think most of the time when I was just attending committee meetings, obviously you've been on the committee quite a lot longer than me, I mostly saw you in Core. So were they all also just fixing C++23 stuff or what was going on there? Mostly addressing national body comments here for C++23.

There were a few new things coming to Core, but this time I was really flying between evolution and contracts and Core and a little bit of library evolution. And core is pretty intense. If you miss a start of a discussion in core, it's very difficult to get back into it. Maybe we should at some point explain what the core does. Yeah, I was just about to say,

we should probably talk about what that means. Yes. So I don't know if people know what a committee is structured, but if you look at the standard, you have two big parts. You have the first 15 chapters, which are the syntax of the language, core syntax, and then you have the library. So when we work in the committee, we tend to sort of split the work into two parts, the part that focuses on core and the part that focuses on library.

And then we have a group that decides on what the new features are coming into the language. And for the first 15 chapters, that group is called Evolution. And this is where all the new proposals come to and people discuss all the merits of it and whether it should or shouldn't be included in the language and once they agree that we want this the author has to write the wording which is the bit that goes into the standard and then that wording goes to a group called core which is really pretty much um language lawyers of the committee so we go through the wording and then we see whether it's um whether it clashes with anything in the standard already there whether it's unambiguous whether it specifies everything that it needs to

specify and there's a lot of meditative thinking there you know you sort of sit down and analyze every sentence to make sure that it really says what it needs to say um and then there's always you know all sorts of funny little corner cases that authors don't always think about but core has to think about it because unless we unless we specify it right there and then someone else is going to come back and misunderstand what the intention was. So that's for the first 15 chapters of the standard. And then for the library, we have a similar setup where you have library evolution, where people bring new proposals for things to go into the library.

And then once the library evolution accepts a proposal, it goes to the library working group with the wording, and then the library sort of cleans up the wording that they got from the library evolution. And then we have all sorts of little subgroups where we discuss specific topics, like we have modules,group concurrency one contracts as you are well very well aware of um that work on a specific topic and then when they have something

that's um that's ready to go into well as long as they think it's ready to go into the standard or start to be discussed discussed in the evolution then they bring it to evolution and then evolution does the usual process so they all have numbers right they all have numbers uh and you know what when i started in the committee 10 years ago we didn't have any of them it was just the four main groups and it's and it's so bizarre how much it exploded i think we have 23 now, safety and security. That was the last one, yeah. Yes. Also a very interesting topic, by the way,

but we can get to that afterwards. Yes, our first meeting in Issaca, I think. But not all of them are active because as a feature picks up and gets released, then we can shut down that subgroup. So I'm pretty sure we had a... Did we have a concept subgroup? I can't remember.

We definitely had the modules one. I think they're now dormant because the feature is actually now in the standard. But we do have a ranges one, which then became reactivated because they keep doing ranges stuff. We have a very active Unicode group. We have a very active,

that's like SG16, I think. Then tooling, SG15 is quite active. SG1 concurrency is very active. I think that we're meeting almost every day in Issaquah. Yeah. And then other than the subgroups that are making progress towards something that's going to eventually be included into the standard, we also have some advisory groups.

We have a direction group, which sort of gives guidance on what the committee should be focusing on. We have the ABI review group that addresses any questions related to ABI breakage. And then we have the admin group that just sort of helps run the committee. And, you know, the things that we've done during the pandemic is really quite amazing. We managed to pretty much release C++23 almost virtually. Most of the meetings in the C++23 release cycle were virtual. So maybe that's a good moment to ask you what actually your role is on the committee.

So I am the committee secretary. I don't make coffee. So you're on the admin group, right? Well, I don't really actually belong in the admin group. I am an officer, which is slightly different. So I pretty much release the minutes from all the admin meetings. Well, I say admin meetings, but I don't mean admin group meetings. I mean the plenary and all the pre-meeting telephone conferences

and make sure that all the decisions are reflected correctly um it's not a particularly interesting role but it is an officer of the committee that does sound like a very important role uh yes you have to be very careful what you say around me because i might minute it yeah the other thing i was wanted to comment on is the thing you said about how core works very much matches my experience i don't regularly go there but whenever i have a paper it usually like ends up in core at some point and then i go there with my wording which obviously isn't very well uh worded usually when it when it gets there and then i remember this experience of just being in this room and people just look at the wording and they're usually very quiet and it's this vibe like you know on star wars if you have like the jedi council

or something and then and then they look at the wording and then it's quiet for a minute and then somebody says something like wait but have you considered what happens if you have like a readic template pack uh like unexpanded readic template pack in this context and then you know it gets injected into your thingy in this way and then and then this other thing comes along and then and then have you considered that case and i was like no i have not considered that case and then they tell me a bunch of stuff that I didn't know about how the language actually works. And yeah. It's funny because we often do that and people say, well, why would you ever do that? And we say, well, we do because we call.

We're going to try and break you as much as we possibly can. But this is the way you tend to hash out all the issues with the wording and all the issues with the proposals. And it may not seem like it's relevant, but it's actually quite important often to figure out things that you think people won't do, but then they end up doing anyway. Is it true that all the members of core are connected via a telepathic link? I just answered that with my telepathic link. It's only a select number of listeners. We'll get there. Right.

So I think one thing that I do want to mention that happened at the last committee meeting is, we mentioned it very briefly, the safety study group, which is SG23 has had its first meeting there. And I think you were there as well, right, Nina? I was for a part of it. Yes. There was, there was a afternoon session on one day and then I think a whole day in the evolution the next day. Yeah.

So, so I was there as well and we had quite a few interesting things so we had jf's paper he is proposing to just make all the uninitialized variables zero initialized instead so we plug a big hole in the undefined behavior land that is responsible for something like 10 of vulnerabilities yeah um we had a paper from um thomas koepper where he said well it's a good idea but we should approach this kind of in a more principled way and not just say you know it's going to do this instead but actually have a concept of like erroneous behavior so that we give tools like the kind of the way to diagnose it as an error but it's still not the undefined behavior so it's kind of something in between which i thought was really interesting and then björn presented like

his whole concept of how we should approach safety and security and cvs in the future and how we should lean on static analysis and guidelines and new library components to kind of basically solve this whole problem of having undefined behavior and undiagnosable undefined behavior in a language so i thought that was a really interesting discussion what i don't know is where this is all going this is something that i think is still very much evolving like you have any thoughts on that yeah it's it's a difficult one i think i think one of the problems is defining what safety and security means is not easy because different people have different views on what is the priority when it comes to safety and security

and then of course there's the whole how do you how do you change things that are already out there to make them more secure like when you when we talk about zero initializing everything that hasn't been initialized you know what does that do to the code that's already out there um and and how if you plug a security hole like that how do you go back and find out the issues? Like if everything all of a sudden becomes well-defined, how do you then find the well-defined behavior that's not correct, which is where the idea of the erroneous behavior comes from, right?

Yeah. I mean, this is something I'm really worried about. Like if you just say, okay, un say okay unidentified variable is now just zero in a lot of cases probably you didn't intend for it to be zero right you actually just forgot to initialize it so it's a genuine bug but now if you have a tool it can't diagnose it as a bug anymore right so you kind of lose that i'm not sure if it may be it takes away undefined behavior but it may make your code like less secure and in other ways where you have like functional bugs right yes and and you know there's there's a you can always look at it from the perspective of either you have a bug or you wanted delayed initialization and you can say well you can you know you can solve delayed

initialization other ways you can have an optional or something like that. But how do you, it's not always feasible to change alt code. It's not always feasible to rewrite everything that you have. I know when I was working for a company that was quite large and had distributed teams, all the teams had to agree on a policy and rewriting and changing policies was just almost impossible. I mean, we do have core guidelines and we had core guidelines for quite a long time. There's a lot of good thing in there, but for some reason they haven't picked up. And I'm just assuming because picking up new policies in companies that have really, really very large distributed teams is it's not always

easy to synchronize and agree on so yeah it's all a bit of a trade-off isn't it there isn't an obvious right or wrong yes it's not an easy problem to solve at all i mean defining it is difficult to begin with solving it is it's it's going to be a challenge yeah yeah i thought that you know when we had this discussion that we even didn't agree on what these terms mean you know safety security correctness and now we need to just agree on what those mean that's highly non-obvious yeah so i looked into this a little bit and i may or may not have a talk on this topic at phil's conference but yeah maybe i can contribute a little bit to that discussion but i'm i think the ball is very much in the court of the people who

came to the committee with those proposals and then evolution which needs to decide on the direction so i'm very curious where this is all gonna go there was there was another proposal um it was only discussed in evolution but it was related to safety and security. Brian Bai, he was proposing plugging a security, well, security, safety issue where you return a temporary object and bind it to a reference

and you don't get a lifetime extension. Oh, wait, I missed that. I must have been somewhere else. Like, I don't remember that is that similar to the fix nico's fix that we got into c++ 23 where you have like a range-based for loop and it's it's slightly different because when we nico's paper offered lifetime extension when you bind it to a reference in a for loop yeah so so that your object doesn't actually die before you start using it but this was more of a every every time you're returning a temporary and binding it to to a reference so

your function returns a reference rather than a value that's almost certainly a bug because you don't get lifetime extension and instead of getting a lifetime extension you it's just ill-formed oh you mean i can't return a reference to a local variable from a function anymore, which is a really bad idea. Yes, yes. Yeah. Okay, interesting. So that actually gets us getting more into this direction

of making things ill-formed that previously were allowed, but just almost always you'd be, right? So we're kind of subsetting the language to something that is a little bit more safe by kind of removing these cases i think that's a very good direction but is that ill-formed diagnostic required i i don't remember the specifics so i wouldn't i wouldn't dare to say what exactly the proposal is but i think that would be significant i need to look this up i totally missed this paper but it sounds very interesting it's going to be on the Evolution Wiki, under the security and safety.

It sounds a bit like a step into the direction that Bjarn is advocating for, basically. He's saying, don't reinvent the language, but kind of subset the language. Have a profile where you say, I care about safety, that you can enable, and then basically make certain constructs reformed where you know the static analyzer cannot prove that they're okay basically this is the gist of

what he's talking about and and i think thomas was making also a good point in in the sense of we can't look at all the problems together we kind of have to separate them into different categories. Nico's for loop lifetime extension fix was mentioned in passing there, but have we actually mentioned that on the show before? I can't remember because it originally came up during the hiatus. That could be worth expanding on, I think. Yeah. So this is something we did actually at the previous meeting in Kona in November last year.

Do you want to, Nina, Do you want to talk about this? Yeah, we can talk about that. Oh, yeah. Yeah, I don't know. So yes, the idea is sometimes you have a for loop. And if you have a temporary that's bound to a reference in the for loop, that temporary doesn't get lifetime extension necessarily. So by the time we get to use it in the for loop that temporary doesn't get lifetime extension necessarily so by the time you get to use it in the for loop it's already dead um and you get undefined behavior and it's not all that obvious that you're getting a temporary always because you can sometimes get

a temporary iterator from um from an expression i can't think of an example right now um and and the idea was well we want to fix that by changing the lifetime extension rules so anything that's the temporary that gets bound to a reference in a for loop has the lifetime extended for the duration of the um uh loop iteration yeah yeah yeah so that paper i think nico was trying for quite a long time to get it in right and then yes i was i for the duration of the loop i said loop iteration but that was wrong it's extended to the lifetime of the entire loop right yeah the entire loop and yes nico was trying to get that in the standard for quite a long time and people are resisting because you know there are downsides to it um because sometimes you might get there's a theoretical degradation in performance that you can get for example if you have mutexes that you lock um that now stay locked for the duration of the loop rather than just for the execution of the iteration expression.

I think somebody even came up with a case where it breaks code, where you lock a mutex in the thingy on the right-hand side of the for loop, and then you expect that it gets unlocked, but it just never does. Or it does only at the very end of the for loop, but that actually breaks stuff. But I think it's quite theoretical, isn't it? I think if you write this code like this, then probably you have, it's kind of already broken, even though it was compiling and doing something.

Yes, there was something like that. I don't remember the specifics. But there was definitely the idea, you know, if your lifetime extends certain objects, they might live for a longer time and you might get degradation of performance. But this is all theoretical. I think somebody did some measurements to prove that this actually isn't a problem.

I don't remember the specifics. Yeah. Well, we can add a link to the show notes to that paper. I think it was very well received because 99.9% of cases are actually where this bites you really badly and it's it's not a new thing um i think we had a core issue for for years i think the core issue was raised sometime i'm gonna say in 2011 or something like that um so it's it's it's been on the committee plate for a long time but it's just well like i said it's very it's been on the committee plate for a long time, but it's just,

well, like I said, it's very, it's very, sometimes it's, it's difficult to agree on things that seem obvious because we don't have enough information or we fear certain things and we just need somebody to do the work and do the measurements and come and convince us that, you know,

it's safe to do. There is a recurring theme of with all these safety things there's always a performance impact and you have to prove that it's negligible or non-existent or worth it and that takes a lot more effort yeah all right uh so nina i want to ask you another thing so maybe you can zoom out from like the individual papers a little bit. You're also one of the directors of the C++ Foundation. Indeed, I am. Do you want to briefly mention what that is and what that has to do with the committee as well? So the foundation is a nonprofit organization.

And the idea is to just support the C++ community and promote the understanding of modern C++. But one of the things that we do is also support the meetings. For example, we were one of the sponsors for the ISACA meeting and one of the sponsors for the Kona meeting. And sometimes when we have papers where authors, papers that we think are very important for including into the standard and for some reasons the authors can't find the time to either travel or make progress, then we might sometimes sponsor that too. And recently we started a way of allowing people to attend the committee meetings so committee meetings are held three times a year and for a long time we had a lot of visitors just coming to the committee meeting

sometimes to observe and learn like that's how I started to be fair sometimes because they have a proposal they want to bring but they're not necessarily interested in participating after one meeting. And sometimes because they are very active in the committee, but they don't have a national body they can easily join. However, there were some changes with the ISO. Well, there were no changes in the ISO rule. It's just ISO kind of tightened up the rules. And they told us that from now on, we no longer can have visitors. We either have to have people who are officially invited by the convener or they have to be official committee member, meaning they need to belong to a national body.

That excludes a lot of people, doesn't it? It does. Unfortunately, it does. And, you know, you can always join certain national bodies that will allow you to pay to be a member of that national body. But, you know, you don't really want to force people who are spending their time, their free time, you know, these are volunteers, you don't really want them to have to pay for the you know privilege of volunteering so um we decided that we should join join insights as a member the the the c++ foundation that's the u.s national body um so now that we are a U.S. member, we can allow people to contribute for free to the committee by being C++ foundation alternates. So when people can't find a national body or when the national body forces them to pay uh we we allow them to become

our alternate and then continue to contribute for free that's super cool so if somebody actually wants to um be involved in the committee but they don't have a an employer that can you know pay for the travel and all of that so what do you recommend they should do uh can they reach out to the foundation they can so you don't necessarily need to reach out you don't have to be a member to attend one meeting everyone can attend one meeting for free so if you if one wants to get interested in in committee work there's there's different ways to going about it there there is an sd proposals mailing list where you can float your ideas about new proposals and things that you want to do and then you get

feedback and support in writing a new paper um or you can just come and see what we do and for that there's a there's a link to isocpp.org um about an email to be sent that usually goes to Herb, who is a convener. And then you get invitation for the one meeting to attend and you can just go and see what we do. And if you want to stick around, then you email me and then I tell you all the different ways that you can try and get an official status and if none of them work out then one can join through the c++ foundation we tend to encourage people to join national bodies if they can if it's feasible because it just it allows them more benefits than just being a c++ foundation alternate but if nothing works out, then we make it one of our alternates

and you can continue to contribute. Great backup plan. Thank you for including more people in the standardization process. I think that's really good. Yes. All right. We'll get back to you in a minute.

But before that, we're going to have a brief message from one of our sponsors. This episode is sponsored by Sonar, the home of clean code. Sonar Lint in your IDE is always free and helps you find and fix bugs and security issues from the moment you start writing code. Add Sonar Cube or Sonar Cloud to enable your whole team to deliver clean code consistently and efficiently with a tool that easily integrates

into the cloud DevOps platforms and extends your CI, CD workflow. All right. So we talked a lot about the committee and what we do there and how to get involved and what happened last week and all of those things. Maybe we can talk a little bit, if you like, about what you do kind of outside of the committee. So you mentioned on your bio that you have a current project where you work on allocator-friendly library types what's that about so we have a few types in the library that are not actually containers so things like optional

and variant and any that if you try and put them into a container your allocator may not work correctly so often when you put a type into into a container and that container has a propagating allocator you want all your all your objects inside the container to use the allocator given to them the problem with types like optional is that quite often you can you can either create them to get delayed initialization so you create your optional with and and it's empty and it's quite difficult to then control what allocator gets used once you create an object inside an optional or even if you do create an object within an optional when you add it to the container you can re-engage it later on and then the information of allocator is lost ah interesting yes i do have a question here i don't quite i don't think i

quite understand this so we're talking about allocators, like, for example, std vector or any of the other containers where you can specify std vector of int and then allocator of int, and then you use your special allocator. Yes. But then those, they allocate their data on the heap, right? Whereas optional and variant, they don't do that. Like everything's on the stack.

So why do we need an allocator for those? Yeah, so let's use a more complex user type rather than an int. So you have a vector of vectors, for example. So you put your vector inside an optional, and then you add that optional of vectors inside a vector. Right. Okay. So now you want all your optional, all your vectors inside your vector

to use the allocator that's specified. It's a propagating allocator. Yeah. And you create your first optional and you engage it and the vector gets the allocator from the parent vector. All works fine until you disengage the optional and re-engage it.

Now the allocator information is lost. So your new vector no longer has the parent vector allocator. So optional doesn't allocate anything. This is the thing. It's an allocator- aware type that doesn't allocate it just it just contains the allocator information for all the objects that get created during the lifetime of the optional object i see and how do you solve that problem do you like write your own optional that basically well you can you can either write your own optional and then have

to worry about all the allocator propagation traits. That sounds like quite a lot of work. It's not an easy problem to solve. So the idea is to put this, we call it basic optional type, inside the library that would keep the allocator and the object within the optional. And then every time the object gets engaged, you use the stored allocator information. So it's allocator preserving optional rather than allocator aware optional.

Like it's not the optional that does the allocation. It's optional that provides the allocator information to the value type that's within the optional um right so yes i'm i'm writing a well i wrote a basic optional type that um uses all the allocate all the allocator propagation traits that we have so when you copy a sign when you move a sign when you copy construct when you copy a sign, when you move a sign, when you copy construct, when you swap, it checks the allocator traits and then adjusts the allocator as needed and propagates it to the value object type.

I see. And is that a proposal targeting the standard or is it just like a library that you write for somebody? So yeah, I did write it for Bloomberg. So BDE now has an optional that does that. The part of the proposal is also a PMR optional, which would be a specialization of the basic optional type. And currently I'm working on a similar thing for variant and for any.

So basic variant, basic any, which is exactly the same problem. You know, you change your type inside the basic variant and you have to somehow preserve the allocated information that was used at the creation of the variant type. Is that going to be a proposal for the standard as well? Yeah, unfortunately, unfortunately didn't go down well um in issaka it got it didn't get consensus um and i have a feeling that

well in general people i think don't particularly like to deal with allocators um they find it a complex problem and and it's and it's one of those arguments you know allocators are difficult and and not a lot of people use allocators so why should we you know why should we waste committed time implementing this but i think that's exactly why we should because it's a difficult problem to solve and there are people out there that need this solved it's it's it's yeah it's one of those things right if you like most of the time you don't need allocators but if you do then you really do and there's there's no other way you can do this without them right no and and like i said it's it's it's not even an easy problem to understand um why you would need this so i i think it well anyway i'm i'm not being

deterred by the no no consensus we are writing another paper with a stronger motivation and like i said i think the idea is to bring a whole package to the committee with all three types together yeah maybe you just have to help them see the bigger picture. Yes. I'm with you on this one. When I was working in audio, allocators are a good tool for stuff like that where you have like a real-time thread

and you can't allocate there because that has non-deterministic execution time. You can't just call malloc on something that's like very time critical right so you write these allocators where basically you have some kind of pre-allocated memory and then they help you kind of manage that so it's probably different from the the use cases that bloomberg has but like the concept is the same yeah it's not not everybody uses the propagation traits that bloomberg uses um i i know that there are environments that use a slightly different

mover sign propagation traits in hope of getting we were saying move assigned to be no accept um so yeah like there are different approaches and in fact i would be i would be quite interested to hear from people that use allocators out there in the wild that would benefit from being able to store optionals inside a propagating allocator propagating container so if anyone out there is listening to this and you are using allocators please do get in touch there you go if you can't reach nina directly then you can always pass that information on through us thank you all right you mentioned also that you contributed to, to Lakers' book and raising modern C++ safely.

That was a lot of fun. You know, I, I pretty much grew up on the large scale C++ software design, which is, which is John Lakers' book. So when he decided to write a book, talking about modern C++ and how to use it safely i was

i was over the moon um and it was a really fun almost a year i think of work um and i think that there was a lot of people contributing, a lot of very smart people, Victoria Romero, Alistair Meredith, Andrea Alexandrescu, Pablo Halpern, Joshua Byrne. There's quite a lot of people. I don't think I can mention them all. But what we did is we wrote a book. Well, John wrote a book. We helped him. A book that's targeting people who are familiar with C++ 03 and want to upgrade to a modern C++.

So what features does new C++ bring? How you can use them safely? What are the pitfalls? And what features are easy to use without getting them wrong and which features you need to be careful about. So the book focuses on C++11 and C++14 only because there's just so much to talk about. So we thought if we split it up in C++11, C++14 book

and then maybe C++17, then 20 and 23, then it's kind of easier to digest. But yeah, we sort of dug into every feature of C++11 and C++14 and then found a way of explaining it in a way that makes sense to people who come from C++03 background. And that was a lot of fun. I think I spent something like a month working through PODs, plain old data and all the things that came out of it. Because we have all these, I'm going to say trivial concepts, not in the concepts kind of way, but just in general.

POD got split up into standard layout and uh trivial types and then there's all sorts of benefits that you get by splitting this concept into two and then having benefits that come from objects being trivially copyable or trivially destructible triv truly constructible, and just having a standard layout, which has different benefits to it. Hang on. Didn't you do a talk at CppCon? I did. I think last year on exactly that stuff. I did. Yes.

Yes, I did actually talk about that. Well, I didn't talk about just that. So I had a talk at cpp con two years ago that was on on plain old data with alice emeritus and we sort of try to uh present everything that we've learned while you know researching for this book but then i also realized that you have all these funky user type categories in the c++ where we give certain provisions to user defined types that built-in types have and i thought it would be just nice to to talk about just present everything that we have so you know aggregate types standard layout types trivial

types literal types structural types implicit lifetime types they just sort of kind of exploded and all of them you know you can if if you write your user-defined types in a certain way you can you can get them to behave in certain context like like built-in types so so if anybody's confused about those type categories they should check out your talk yes although i'm not sure it's actually online yet as of right now i don't know i haven't i so they're still being released yes the youtube channel says premieres on the 10th of march so i think you'll have to wait a little bit longer until you can watch it but i'm not sure whether I can watch myself.

We should at least be able to put a link in the show notes. Yeah, yeah. We should put a link in the show notes and then say, you know, this premieres in a few weeks. And then once it's out there, you should check it out if you're confused about those categories. Yes, it's quite a lot. You know, it sounds like there's not a lot to talk about, but there is.

And I'm actually doing a slightly expanded talk at ACCU in April in the UK. Oh, cool. Well, I'll be there too. So I'll make sure to check it out. I'll make sure to be in the room for that talk. Because I actually also am sometimes quite confused about those things, even though I'm supposed to know this because i'm on the committee was actually not that easy to you know remember what the difference is

about not everyone knows everything um implicit lifetime type or uh like like uh all of those things interestingly at c++ 20 in inissica i think we added the implicit lifetime trait didn't we oh yeah that was that was my paper with Vittorio. So Vittorio had the idea, and then I kind of produced an actual paper. So, yeah, that was a trait to figure out whether a type is implicit lifetime. And we got it in the C++23 past feature freeze because we argued that it's actually really important to fix bugs because you have this problem.

So we have now these implicit lifetime types where if you have a chunk of memory and then it comes from a magic blessed function that creates implicit lifetime types like malloc or something, and then you just reinterpret cast it to a pointer, like that always used to be UB, but now we say it's not ub because you know an object of the correct type just magically springs into life if it's implicit

lifetime but the problem is that it's one of those user categories that nobody including myself can remember what the actual criteria are i mean you probably know this because you did a talk on it but it's like what was it like for implicit lifetime type it has to be either an aggregate or or has only public member i don't even remember but like something like this there's like a bunch of criteria yes trivially constructible i believe yeah that's it you need to have at least one constructor that's like trivial or something yes and so now the problem is what happens if you go to your class definition and then change it such that it's not fulfilling those criteria anymore. And what happens then is that your code is now silently turned into UB.

And that's really bad, right? And so that's why we wrote a trait so you can actually, you know, make something depend on that trait being true. So you capture those bugs. So that's how we got the paper in it's scalar types array types aggregate classes and classes with a trivial destructor and at least one trivial constructor although there's there's still some uh motion in core on whether that's well specified interesting okay watch the space watch this space but yes i'm going to have to update my

my talk because i do talk about all the traits that you can use to recognize whether your type is one of these categories and i didn't have a trait for implicit lifetime so now i can put that in but yeah i think it definitely proves why why your talk is so valuable once it comes out because um you know i literally wrote a paper about this trait and i i still i can't remember myself what the criteria are like for implicit lifetime types yeah i think it's one of those things where you kind of have to be aware of the things that you don't know because remembering all the rules for all the category types i don't think it's possible i i i don't remember them i had to i had to remind myself right now so it is one of those things where you have to go back and check whether

your knowledge is correct or use a trait all right cool so um i think we're ready to wrap up is there anything else bill that you want to talk about with nina no i think uh i think it's a good time to to wrap up to bring the implicit lifetime of this show to a conclusion well thank you for having me this was a lot of fun anything else you wanted to to bring up before we let you go nina no no thank you for this all right well thank you so much for being a guest on the show. Do you want to tell our listeners how they can reach out to you if they have more questions about type trades or things like that, or the C++ Foundation or all the other interesting things that you mentioned? You can always email me and I hope you can provide an email somewhere because it's

dinka.rans at gmail.com rather than nina.rans at gmail.com so if you can if you can put that somewhere in the C++ I would really like to hear from people that are using allocators and sort of pick their brain on how they're using

their allocator traits and what they do with propagation that would be that would be awesome all right so please write an email to Nina about that what they do with propagation, that would be, that would be awesome. All right. So please write an email to Nina about that. Okay. Well then thank you again for being on the show and see you, see you next time.

See you next time. See you at ACCU if nothing else. Yeah. See you at ACCU. 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 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 timor underscore audio on Twitter and at timor underscore audio at hackydm.io on Mastodon

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 Postcard website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.