CppCast - Unicode Progress and C++/C Study Group

Episode Date: November 5, 2020

Rob and JeanHeyd are joined by Aaron Ballman and Peter Brett, both members of the ISO C++ committee. They first talk about an extension for Visual Studio and Visual Code for visualizing struct layout and a blog post proposing a safer boolean type. Then they talk about Aaron and Peter about progress being made at virtual ISO meetings and the upcoming virtual Plenary meeting. News StructLayout Visual C++ Extension Fun with Concepts: Do You Even Lift, Bool? Meeting C++: My thoughts on "The... Community?" Links ISO C++ October 2020 Mailing P1787: Declarations and where to find them WG21 SG16 Unicode study group Editing the C Standard Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license PVS-Studio: analyzing pull requests in Azure DevOps using self-hosted agents Why it is important to apply static analysis for open libraries that you add to your project Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Thank you. And by JetBrains, the maker of smart IDEs and tools like IntelliJ, PyCharm, and ReSharper. To help you become a C++ guru, they've got CLion, an intelligent IDE, and ReSharper C++, a smart extension from Visual Studio. Exclusively for CppCast, JetBrains is offering a 25% discount on yearly individual licenses on both of these C++ tools, which applies to new purchases and renewals alike. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com to take advantage of this deal. In this episode, we talk about visualizing struct layout and a better bool. Then we talk to Aaron Ballman and Peter Brett. Aaron and Peter talk to us about their work on the C++ Committee. committee.

Welcome to episode 272 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my guest co-host, Jean-Huidh Manid. Jean-Huidh, how are you doing? I'm doing pretty great. Excited to guest co-host. This is the first time I've done something like this. So, you know, I'm kind of excited and happy to have our two guests on for this. Yeah, should be fun. And for listeners who are wondering where Jason is, he will be back next week, but he was unavailable this week.

And over the past few years, Jason's been doing more and more training and international travel. And we've always you know sometimes had difficulty juggling around that schedule sometimes we might record two episodes in a week beforehand or try to work with his schedule when he is international and record interviews then and uh sometimes it's difficult and sometimes we missed episodes in the past because of it so the two of us uh discussed a while ago that it might be a good idea to instead of working around that sometimes difficult schedule to just be able to have alternative or guest co-hosts and uh sean he'd you were one of the first people we thought of uh and it's great to have you on uh

in jason's shoes this week i hope i can hope i can fill up i'm sure you will okay well at the top of every episode i'd like to read a piece of feedback uh this week i got this tweet uh from pixie mix saying hi there i'm fairly new to the podcast and just getting up to date with your episodes loved your more recent one with theresa johnson i love the atmosphere of the show so far and the higher level of it being for CPP programmers as opposed to beginners. Please keep it up through tough times. You've given me a good new morning podcast. So yeah, thanks for the great work, the great words. And yeah, it was really fun talking to Teresa last week about thin LTL. Cool. Well, we'd love to hear your thoughts about the show.

You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Aaron Ballman. Aaron has been a professional software developer for just under 20 years, most of which has been spent working on compilers of some sort.

He currently works as a senior staff compiler engineer at Intel, and most of his compiler experience is from working on Clang. Aaron is the code owner for a few things in the Clang community, attributes and Clang query, and primarily focuses on the compiler front end. He's been a member of the C++ committee for about seven and a half years, and of the C committee for a little over four years. He has a personal interest in getting involved in committee work around security and safety. He wants to find ways to make it harder for programmers to write bugs in the first place and make it easier for tools to tell programmers about the bugs they've written. Aaron, welcome to the show.

Thank you for having me. Good to have you here. And also joining us today is Peter Brett. Peter is currently based in Edinburgh, where he has been working on electronics design automation software since 2006. He spent several years of his free time as the maintainer of the open source GPL, electronics design automation schematic editor, and carried that experience over when he joined Cadence Design Systems in 2017 to work on the schematic editor component of Virtuoso,

their flagship custom integrated circuit design suite. Peter learned the program in C in 2004, picked up C++ in 2013, and started contributing to C++ standardization in 2019. He is currently the assistant chair of SG16, the Unicode and text processing study group. Peter, welcome to the show. Oh, well, thank you for inviting me to join you.

Yeah, it's great to have you here. So we got a couple news articles to discuss. Feel free to comment on any of these, both of you, and we'll start talking more about the work you've been up to in C++ Committee, okay? Sounds good to me. Sounds good. So this first one is a struct layout visual C++ extension. And I saw this on Twitter over the last week a lot, John Heed. This is a pretty neat little tool, isn't it? Yeah, it's actually pretty amazing.

You know, being able to kind of visually see, you know, all of the alignment that you get out of a certain structure, where the V table is and things like that, you know, or where the V table pointer is and, you know, where the base class is located, where the actual members are and how big they are in relation to one another. And also it shows, like, the really cool thing about it is that instead of just, like, kind of packing everything

in one, like, list of things, like, it actually leaves empty space. And so you can see, like, gray space where you can visualize, like, the empty padding by its use, right? So if you move around members, you can see like gray space where you can visualize like the empty uh padding but by certain use right so if you move around members you can see like that being played with and and the changes of where those things are and how well you can pack stuff together so it's it's really cool and it makes it a lot more accessible because it's like visual and so you can kind of you know play around with it uh uh a little bit it makes it a little bit easier to play around these things and kind of immediately get that feedback of how it is

rather than trying to do a bunch of stdc outs or print tabs to figure out where the struct is located in the offsets and using offset of and then a bunch of other stuff. This is pretty cool. For our listeners who if you go and click on this link

you'll see this little animated GIF which is really cool but you just right click in Visual Studio when you're looking at a structure or class, and you can choose this option from the extension to get a visual struct layout, and you get this really nice, broken-apart, kind of color-coded graph of the alignment. It's really, really neat. I would use this so much if I wasn't an Emacs addict. But I think when I was looking at this

and thinking quite often the order of the member variables in my classes in C++ is determined by the order of initialization. And I can't actually reorder them even if there are huge gaps in the class layout. And I was thinking about that and what we could do to improve that in the future.

That's what came to mind when I was looking at this myself. Yeah, that's a good point. I really liked it as well. I like the fact that it was in both Visual Studio and VS Code, so you can use it kind of in different editors with the same user experience. But I personally, I just love visualization tools like this because

I'm more of a visual person, and so it does a great job of showing me where my gaps are. But I did find a couple of small problems with it. I noticed, for instance, that if you have a templated structure, it won't actually show you the fields in the structure

because it doesn't know about the instantiations. And so I'm hopeful that as they get feedback, this will continue to improve. But I already think it's a super useful tool and I'm really glad that it was founded on Twitter basically. Yeah. I know with kind of, you know, regular visual studio, they've have a fairly new feature where you can like give a default type to, you know, a templated class. So maybe they could do something like that where you, you know, give a type to this visual layout tool,

and it'll give you a visual layout based on that type. Yeah, and I'd also mention that perhaps it might make sense to allow you to inspect the type of a variable so you know the concrete type of the instantiation at that point. That would be really useful. Yeah, I agree. Okay, next article we have is from from vector of bull's blog and this is fun with concepts do you even lift bull and i thought this was a great article john he'd um i they go into um you know the the weakness of of bull uh and you know its problems with implicit conversion, pointers implicitly converting to boolean.

And at the end, they give an alternative boolean type that would avoid all those problems. Yeah. It's really the... I kind of like it because it is a very good alternative to bool, but I think there are some other things that you can kind of get out of this that probably require a little bit less work than making your own struct boolean. And that's probably because it's just a little bit better to have named things instead.

When you pass things like true and false to constructors or function calls, if you have just one, it might make sense. But we know when we get the two or three, or, you know, or it's one, but it's interleaved in a bunch of other members are a bunch of other different parameters, it becomes a little bit difficult to kind of sort through whether or not, like what that's actually supposed to mean. So a lot of people kind of go with the nums here where they use an enumeration and then give it a name. But just on its face,

you're just using Boolean values. Like the whole struct Boolean that they define here is actually super duper useful. There's another technique also that you can use to kind of prevent just like implicit conversions, which I think you mentioned at the very end of the article, where you use that, the same asterisk or an identity T trick where you basically,

you have a template, you use a templated type that basically just resolves the same type you pass in. So it's like identity. It's like same as bull or identity T of bull. And basically what that does is that prevents that prevents like the different kinds of template instantiations and conversions from triggering And basically what that does is that prevents, uh, uh, that prevents like the, uh, different kinds of, uh, uh, template instantiations and conversions from triggering, uh, automatically. Um, and it prevents the, you know, a couple of deductions like that when you're in template

context. So that also helps a little bit too. Um, so, you know, that's, it's also kind of, uh, uh, kind of helpful. Yeah, definitely. I missed that last part about the, uh, same as trick. Yeah, definitely. I missed that last part about the same-as trick. Yeah. The same-as trick is more of employing a concept to prevent the

conversion from kicking in. So you same-as bool auto B, and that gives you a parameter that is stretched to be basically boolean pipes only. But the other kind of lower tech, non-C++20, non-concept version

is to just use an identity T trick to prevent some amount of implicit caching and decay and stuff like that. So there's two different ways to do it. I prefer the concept version because it's a lot cleaner and it's a lot easier to read. But other people working on C++17, you know, other people, you know, work on C++17, they don't have concepts,

or, you know, work in C++11 or, God forbid, C++03, and so they have to do some different things to make it work out, I think, yeah. Right, right. Aaron or Peter, anything you wanted to add to this article? I appreciated the fact that it was a nice demonstration of how to, what the power is in some of the new declarative syntax in C++.

Things like having conditionally explicit constructors and that sort of stuff. I like seeing more emphasis on those sorts of safety aspects where the C++ committee way back in the day kind of got the defaults a little bit wrong, perhaps. And so this gives users a path forward to writing a little bit more type safe code with less implicit conversions. So I thought

it was great. I did think it was really interesting. There was just a tiny little note in there about how concepts are supposed to make error messages so much easier to read. And the author did not find that to be the case. And I keep hearing that over and over again. And as a compiler writer, it makes me sad because that was one of the things that we were really hoping was going to improve with concepts. And so I'm hopeful that we'll continue to improve the compiler technology to kind of reduce the amount of template instantiation-ness of concepts, if we can. I mean, I was going to mention all of the stuff that Aaron just mentioned but one additional thing is that this thing about language defined conversions taking priority over user defined conversions and one of those language defined conversions that causes me a lot of grief is a way to point to decay and um even with concepts i i really struggled to find

a new way around that who knows in uh in 2023 or 2024 we might get a c++ 20 compiler to use on our product and i might be able to do some more in-depth experiments then. But yeah, I really found that theme of, you know, slight maybe problems that have built up in the standard over time where sort of a number of sensible decisions have sort of added up something we're not totally happy about. Really was an interesting sort of second narrative to this article that I enjoyed. Right. Okay.

And then this last article we have uh john heat it's great you're here this week uh it's kind of ironic because when we had um jens veler on a couple weeks ago we talked about your video uh the community and he mentioned at the time that he was going planning on writing writing his own blog post on the subject. And he has since written that blog post. And he's sharing some of his own thoughts here. And now we have you here to talk about it. Yes, I guess I was pretty lucky.

But yeah, so his blog post kind of goes through kind of a more specific to++ uh look at like the community and what they can do and you know the kind of uh what kind of the challenges that that that that meeting c++ faces um i also found particularly in the article i found the point about like data collection very interesting um so so like uh you know in the article i believe it's like it's like as a german like i'm i'm uncomfortable having detailed tracking on this on like this kind of data because, you know, so I don't have it. Right. That's why he said he didn't have it. A lot of what got a lot of minority groups and ethnic groups in trouble is that when they were invaded or whenever the country wanted to look inward, they had very detailed information about what ethnicity a person was and what culture they affiliated with, what religion they affiliated with. And so that made it so that it was very easy and effective in, like, you know, deporting people, putting people in camps, you know, getting them out of their country, attacking them, et cetera, et cetera. And so a lot of the, you know, this happens in France and other places, right, where they kind of outlaw collecting some of that data, like on race or ethnicity and things like

that, because they're afraid of that. If they have that kind of detailed information again, then, you know, somebody goes off the rocker, you know, to France or Germany or, you know, Austria or whatever. Somebody could do that again. Yeah, yeah, yeah so so that was a very interesting point and it kind of squared with with what i was doing so i found a lot of of good data on like uh you know ethnicity and and and things like that in uh in in asia um and in the united states and some of the uh south american countries as well but where it kind of fell off uh was in europe and in the United States and some of the South American countries as well, but where it kind of fell off was in Europe. And that's kind of because of that culture of like being careful and not snacking that kind of information.

There's still at least some good data there around like women and, and, and other other kinds of splits in the community. But, you know, a lot of people can, again, a lot of like the culture around Europe is like not tracking the data to begin with, because they're just that, that, that fear of, you know, what would happen if this got into the wrong hands and things like that. And that's, you know, it's a very valid concern. And like, being able to properly convince yourself that you can collect this data and properly anonymize it so that something like that wouldn't happen. It's a very tall order. Especially, you know, if you're a single person managing a lot of this stuff.

I found that point very, very interesting, and it gave me a lot to reflect on for some of these conferences like that. That's a very good point. Aaron and Peter, do you have any thoughts you wanted to add on this one?

This made me think about this article made me think again back to John Heade's excellent video. And I was thinking that really, there is a very, very small number of, you know, real racists and misogynists and things in our community. But I think, there is a lot of us. I think people who don't want to need to worry about these things as things that need to be dealt with within our community. There's not so much, you know, the problem for me is not so much the actual racists, it's the people who want to be free from thinking about that as a problem that people who come to our free from thinking about that as a problem that people who

come to our community have to deal with and for me that really when I was reading through you know the comments in all of the different forums that was what I really saw that was the first thought and the second thought was that one thing that I struggle with is getting my colleagues from underrepresented groups to take part in, you know, events in our community. And often even when, you know, even the hurdle of being confronted by a blank sheet of paper for a call for papers is very difficult for some of these people from those groups and i don't really know how we can tackle something we need to think about as meeting organizers and as sort of professionals within the communities how we can address that that barrier to entry yeah yeah i think one of the things Jens mentioned was it's just great to have someone that you can look at

who looks like you as a role model speaking at these conferences and things like that. And the more of those role models we have, hopefully the easier it becomes for more people of various minorities to kind of join the community and feel like they can be a part of it so hopefully that just continues to happen okay oh yeah okay so uh normally uh on a normal year uh over the past few years of cpp cast um we do several uh-ISO meeting kind of trip report episodes. Usually we'll grab someone who was at the meeting and talk about what type of news occurred there.

But obviously we haven't been able to do one of those since we had Hannah on the show, I think, back in February, right after the Prague ISO meeting. But work is still happening. And we thought it would be a great idea to talk to a couple committee members who have been active over the past few months, and kind of get a pulse on what sort of progress has been happening. So we could we start off by by both of you just telling us a little bit about your perspective on recent virtual ISO committee meeting work? Maybe start with you, Aaron. Sure. So 2020 has been a really interesting year in that it's been difficult for me to follow the thread of what's been happening in WG21 because there are so many meetings happening at all points in time. Even though we're not meeting face-to-face, we're meeting virtually, and we have 20-some-odd study

groups that are meeting virtually along with the four working groups. And so, I think in the month of November, I counted six weekdays that did not have an ISO standards meeting for WG21 on them. And that makes it a challenge to try and keep up with what's happening. Mostly I've been kind of lurking on things. So I've been paying close attention to what's been happening in the core working group, which is where I usually sit during the face-to-face meetings. And the most interesting work that I'm seeing there is P1787 is a paper from Davis Herring that is an omnibus paper fixing over 70 core issues in one go. This thing is a gargantuan amount of effort on the part of Davis and the whole core working group to make sure that the wording

changes are all correct. And it's something that will be coming up for polling in November at our plenary meeting. And I'm really excited because it's pretty rare that CORE gets to close that many issues in one go. It's usually one issue here, one issue there. And getting through that backlog has been really, it's great that we're taking this opportunity to go through it. What types of issues are in this paper? I mean, 70 sounds like a lot of things. I'm guessing most of these are pretty minor tweaks?

I would say it's more that we weren't happy with the state of the art in the wording. And so it's fixing a lot of little, a little tiny details. So it's things like fixing definitions, fixing how lookups work, fixing declaration matching, working on modules, parsing.

So, I mean, it spans kind of the gamut of everything in C++, but it's mostly just this issue came in and nobody got around to resolving it yet. And Davis just took a whack at it and really knocked it out of the park. Okay, cool. Peter, how about you? what's been your take on virtual c++ work over the past few months i mean for me it's been a really important improvement in the way that we do things

in wg21 um i i have colleagues here in the uk who are really C++ experts but who have caring responsibilities and can't you know go off to the other side of the world for well usually over a week to spend 14 plus hour days in meeting rooms and I think that this and then we know about disabled people who find it difficult to travel by air, and we know that there's a lot of places in the world where, with the best one in the world, you can be an expert in C++, but you won't be able to afford or gain permission to travel to our conference. So having this virtualised process has the possibility to throw open the doors of WG21 to all sorts of expert contributions that we haven't previously enjoyed. Now, in terms of the work I've been doing, I've mostly been focusing on the Unicode side of things.

And back in San Diego, when the Unicode study group was first set up, the expectation was that we'd be defending all of our time on library stuff, you know, libraries for handling text encodings, improvements to the locale system, I.O. sort of improvements. What we discovered a few months ago, well actually towards the end of 2019, was that one big area where Unicode and text processing has an effect is actually in the specification of the C++ language itself. So we've taken this great big turn around and all the papers we've been discussing this year, almost all, have been to do with improving the lexing and parsing of C++ source code. And we've got some quite cool direction no longer throw poop. We have fixed multi-character literals.

We've solved what happens when you have trailing space followed by a slash at the end of a line. Sorry, a backslash followed by trailing space at the end of the line, see even I can't get this right. And all these little details are just going to improve the portability and reliability of standard C++ source code, and make it so that the program you got as much you get at the end of the compilation program SS doesn't really care about how you provided the source code to the compiler. So, yeah, that's really what we've been focusing on. And who knows, maybe next year we'll get on to that text library stuff we were aiming to do in the first place.

Sean, you look like you have some thoughts going on. No, I just clutched my chest a little bit there because losing emoji and identifiers kind of made me sad because I was absolutely, like some people use it in slides, but I was absolutely the meme lord that put emoji in their

code bases. So I was that co-worker. But yeah, I mean, it's for the better that we're kind of cleaning this up and that you know we're following uh what is it uax uh 40 31 31 ux sorry ux 31 where it talks about identifiers and how you're supposed to you know how you can find amounts like that um it does kind of exclude a like one or two languages because of the way that zero-width joiner sequences and other stuff are excluded. But I think that would be something that we would go to the Unicode committee and kind of get them to fix it. And then kind of bring that improvement back to C++.

So emoji aren't gone forever, but someone has to commit to the work of going all the way to the Unicode committee and convincing them to fix it and then putting it back to C++. And maybe that's like a six or maybe even a nine year process. So, you know, I don't know how long the Unicode process is. But yeah, so, you know, I just I was hurting a little bit for for putting putting flags and emojis and poop and running man are some different colors, and even different colored blocks for like, you know, formatting and stuff. I'll live, but it hurts a little bit. One of the advantages of

taking on the Unicode definition of what an identifier looks like, I know we're heading off into the weeds here, one of the big advantages is it makes us have the same set of identifiers available, as in a whole bunch of different other programming languages, all of which have also adopted this Unicode specification. So now if somebody

goes and works on improving the Unicode standard for this, then all of those different programming languages benefit. So I know that includes, for example, Rust and JavaScript and a couple of other programming languages, Java. When we have a sort of a common standard for how we write identifiers in programming languages across the programming language ecosystem, it makes it easier to write code in principle that interoperates between different languages or to like transliterate useful libraries from one language to another. So I think this is overall a good step, although I really do sympathize with John Heath's disappointment. Speaking of cross-languages, Peter, do you know if SG16 is looking at taking some of that work over to the C Committee as well, so that we can both benefit from a common subset?

Or is that not necessary? Is that a gargantuan ask? Well, Sean, he's already made the first steps in terms of fixing the peculiarities of white space at the end of lines. I'm sure he's got other stuff up his sleeve. Ah, Jesus. Yeah, so I unfortunately put myself a little bit on the hook to kind of take papers between

SG16 and the C committee. And I've already published one in the last C mailing, the mixed string literal paper, you know, for not being able to mix like, you know, two different wide string literal, right? So if you have L and then U, capital U for UTF-32, right? Because like mixing those is like a very kind Because mixing those is very conditionally supported, and most compilers don't even support it anyway, except, I believe, for SDCC, the small-to-by-C compiler,

where they took the first prefix. But even then, the primary maintainer developer works on that, Dr. Krauss, kind of just said, yeah, I'm not sure anyone even uses this feature. We kind of just implemented it because why not? So there's a lot of work going on trying to make it so that there are things that, like Peter said, that we can have more portability of source code and everything else, making it so that when you do something on one platform, you don't go to another platform and then everything explodes.

So that's a pretty good thing to kind of move in that direction, though I am a little bit sad that I not only did I sign up, it's kind of a double whammy because I signed up to do the work, but if the papers get approved, then I'm also the one who has to put them in because I'm the product editor, so I'm signing up for twice the work. It just doesn't sound like a

good idea i might add john heath that your blog post on your editing process for the c standard was fascinating and of course i encourage to all of the listeners to go and read that it really shows you how the sausage is made yeah agreement yeah it's it Yeah, it's a fun process. Thankfully, I think the C++, the way that C++ source for making the standard is also in Littek, but it's kind of written differently and structured a little bit differently.

And I think the reason that the C++ standard has a better organization of source tree and everything is just where it came from. In the C case, it came from an old language called trough at the time. And that was the way people were writing the standard. And then they ported the trough from that to LaTeX. And then the actual, you know, trying to take that LaTeX and kind of like slowly move it from being like a trough and LaTeX mix up to being like purely LaTeX and getting some of that good, you know, good organization in has been kind of an interesting journey. I've got this big set of improvements I want to make to the standard.

And don't tell anyone from the C committee, but I'm actually thinking I might introduce stable tags into the C standard so you can actually instead of remembering section numbers, you actually get to remember environment.limits instead of 5.2.2.4.1. I hate that I know that.

Yeah, but hopefully these kind of incremental chains will kind of start slipping into the C standard and the torque will get better. And, you know, working with it will get better and, you know,

hopefully integrating papers will be faster and better and all that kind of stuff. I'm, I'm very excited about stable tags, probably to the point that I shouldn't be that excited. Oh, me too. Yeah.

It's, it's, it's one of those very small things like that. Like I kind of took it for granted when it showed up in the C++ standard. When they have the decl.exper or all those sorts of things, I just kind of thought that's the way people do standards. And then I looked outside the C++ standard and I saw that, oh my god, everybody still references things by section numbers.

And the way people keep stability is that they never change section numbers. They just keep nesting things underneath each other, and that's how you end up with 5.2.2.4.1 and stuff like that. I hope that we can steadily move towards stable tags in C standard to make it easier to reference stuff, so when you talk to

people and things like that, you can have a better lexicon that jogs the memory. I know what env.limits will probably map to, but I have no idea what 6.7.2 is supposed to be. I can't emphasize enough how important these stable

tags are, even outside the standardization community. When I have a coworker come and ask me, I don't understand why the compiler isn't compiling this the way I expect, then it's so useful to be able to see, well, go and look at this stable tag about, and it will take them directly to, oh, it's initialization. It's always initialization. It'll take them to

exactly the paragraph that they need to, to understand why they're getting some bizarre type of initialization when they're expecting to get value initialization. And so, yeah, the stable tags are really practical for sort of like everyday compilation debugging, not just for standards nerds like me. Yeah, definitely. I want to wrap the discussion for just a moment to bring a word from our sponsor, PVS Studio. The company develops the PVS Studio Static Code Analyzer, designed to detect errors in code of programs written in C, C++, C Sharp, and Java.

The tool is a paid B2B solution, but there are various options for its free licensing for developers of open projects, Microsoft MVPs, students, and others. The analyzer is actively developing. New diagnostics appear regularly, along with expanding integration opportunities. As an example, PVS Studio has recently posted an article

on their site covering the analysis of pull requests in Azure DevOps using self-hosted agents. Check out the link to the article in the podcast description. If we don't mind, I want to rewind a moment back to something, Aaron, I think you said a moment ago, you made mention of a virtual plenary coming up soon. And, you know, we've had, I guess, you said there were online meetings for the ISO committee almost every day of the month. But is this virtual plenary that's coming up soon the first one since the last in-person plenary back in February? Yeah. So this will be kind of our first opportunity for the whole plenary committee to stamp the work that's been happening in these virtual meetings.

And so I'm curious to see how it goes. But like Peter, I think this is a great opportunity for the C++ committee to get a lot more people involved who wouldn't otherwise have the ability to get involved. And so I think the accessibility of the meetings is great. But I'm very curious to see if the plenary means that there's going to be more features or less features. I don't know. I don't have a good sense. Is the pace speeding up because more people are able to participate?

Or is it slowing down because it's a different format and we all are trying to figure out the hiccups? Right. So how much is expected to happen at the virtual plenary? I think I heard that, you know, there was kind of informal voting happening on various papers where everyone, you know, kind of is agreeing that they approve of this paper, but they won't actually vote on it until the next plenary. That's kind of what's going to happen here. Yeah, that's the usual process in WG21 is the different working groups and the different study groups will take their own polls to say, our group believes this about this paper, and nothing gets officially adopted into the standard

until the plenary session when the people who ISO has blessed for voting basically say, this is our position on this feature. And so without holding one of these plenary sessions, we just don't have the ability to actually instruct the project editors, please go make these normative changes. I think one other interesting thing is there's this roadblock in the standardization process now between the evolution working groups, which decide how we want the standard to evolve, and the wording groups who say, well, this is how we're going to standardise this thing you asked for. What are the actual

words that go in the document? And the roadblock is, if an evolution approves something, it goes to be approved by planar before going out, before going to the wording group, as I understand it. Oh, that's interesting. Planar meetings delay, I think is a better way of describing it. I don't think there's actually going to be any straw poll in the planar meeting, but there's this need to wait to advance stuff and not having a tentatively ready status, I think

it's... The status is called tentatively ready, and its whole point is to basically give people time to look at this stuff. Before, whenever we voted on stuff in person, that was the bottleneck. If you you were in the room you saw the vote go up right people you know pinged each other on irc or wherever they were and basically asked people to come if they had special interest in certain papers right so there was always like this

bottleneck where you could always be there um and that bottleneck only happen like three or four times a year, right? The other kind of portion of this that's kind of changed now with these virtual meetings is that because we're having basically what amount to like little evolution meetings every week, basically, we need a way of kind of queuing up a bunch of work without just kind of like passing it through every week, like rapid fire. So, you know, that's why tended to be ready ready was introduced that's why we kind of like wait a little bit make sure that there's no outstanding objections kind of make sure that it's all good and then we kind of move it over to the next stage um so that we kind of uh we still have you know checks in place to make sure that somebody can you know raise an objection or do something or feel like they have the time to read a paper even if they missed you know the one the special one

hour slot you know because it was at 2 a.m their time on on their side of the world or something um so that's that's kind of why the tentatively ready check and that kind of thing is there the planary is so important because it means we can make progress on all the stuff that's sitting in the queue. We can move the next batch through and then move on to the next pieces of work. So I'm really excited about this planary coming up because it's going to give us the next chance to make some progress on the standard. It's the next chance to move chunks down the pipeline, if you like. Yeah, so I'm actually particularly excited about this virtual punny

because a feature that I actually got approved back in the 20 timeframe, the literal suffixes for size T, that was kind of pre-approved to get into C++23, but not 20 because it was too late in the cycle. So my paper is actually one of the things on the ballot, actually, for core and for being approved as plenary. So, you know, that is one of the first features, I guess, that is going into, you know, C++, the language. So I'm actually pretty excited about that.

And that actually helps me fulfill one promise I made to a physicist, to Ryan Halberthma, Dr. Ryan Halberthma, who was the original person who put that paper through, but then kind of, you know, had other things to do. So he kind of dropped it in the CES 17 timeframe. And so I picked it up. And so carrying this through kind of fulfills history and, you know, and, you know, even in the middle of pandemic,

we get to kind of make, make, make that work out. So that's, that's pretty cool. And, you know, there's a couple of things that are also getting through that are actually pretty cool in the library side um but i think overall though there are there are less motions um on this plenary despite having like a much wider gap of time uh than you would normally see at i think a plenary meeting right so uh to give it to give an example like the last the last in-person plenary like at prog and that that's kind of a bit exceptional because we were proving cs plus 20 um stuff um but uh that had like 50 plus motions easily on on uh for things that we were trying to

prove um but what's what's been interesting is that on on this uh this plenary this virtual plenary that we're doing even though we've've had a much wider gap of time, instead of meeting in the summer, usually we miss that meeting and we kind of keep going. It's been nine months, right? Yeah, it's been nine months of time. But we only have, I think, 11 motions between both library and language or something around there. But it's definitely not like 40 motions like before. So there's a lot less there's a lot less papers being pushed through i think um and i think but i think this maybe that

will kind of change because for a lot of the summer and everything else we were basically trying to figure out like are we going to have meetings like what's going on so i i think it's a little bit unfair to say that we we have nine months of stuff and we didn't get nearly as much done i think it's just that we have spent a lot of time spinning up the process and how does it work virtually and all that kind of stuff and now that i think that we've got this kind of ball rolling i think we'll kind of return to a little bit closer to what we were putting before and and that kind of stuff but you know i'm not sure if we'll get all the way to having like 40 50 plus motions uh plenary um but yeah right i think one of the other reasons for for having a few emotions is

kind of people have been taking this as an opportunity to work on like big ticket items so aaron was already talking earlier about this massive single paper that makes huge improvements to the core language wording i know that in the library side, you know, they've got the networking paper that's had an awful lot of attention. I mean, dozens of hours of library working group time and library evolution has been spending a huge amount of time on executors. And the thing about executors, right, is like they've got dozens of papers on that but eventually when that comes to you know straw poll and planary it'll be one it'll be one motion add executors right and and so and so i think in some ways the more distributed meetings um the more frequent

meetings the more frequent paper mailings as well let let's not forget that, have meant that it's been possible to make more focused progress on some of those really big ticket C++23 items. So I wouldn't take the small number of store polls as being an indication that, you know, we've settled a pipeline stall, as it were. Yeah. Okay. Well, I guess you kind of touched on this, and maybe we'll know a lot more after this November plenary.

But one thing I'm thinking about, and I'm sure listeners are curious about, is how much might this affect C++23? I mean, hopefully the world goes back to normal, and you can start having normal face-to-face meetings again. But do we feel like significant work is being done and C++ 23 should still be a significant release? Or do we think it might be smaller because of the COVID pandemic? I honestly don't know. It's so early in the process to to really be able to to predict but um i think it i think the the good thing is is i feel like we've really done a good job of working a lot of those kinks out of

our process stuff and so now we can start seeing what our more realistic pace is like and whether whether that impacts things or not but i do know that for instance one big ticket item that is still being heavily worked on for c++ 23 is contracts. That was slated to be in C++20, but it didn't gain enough consensus and so it didn't make it there. And the contract study group has been meeting and trying to continue to make progress on contracts for C++23. Now, whether they'll hit that target or not, it's still way too early to say. But it's not like we've halted all big feature work to go try and clean up bugs in every corner. In terms of the schedule, I know that Herb Sutter, the chairman of WG21, is absolutely

committed to making sure there's going to be a C++23 standard, no matter what the content is. There's a train model we have where, we have where if your feature misses the train, well there'll be another one along in three years. And I think that's a good approach to take because it means that if a paper's not ready or a feature's not ready, it's not the end of the world, it's not going to hold our things up. And there's already enough things going to be in C++23 to make it a really worthwhile language upgrade. Do you want to talk a little bit more about specific papers or study group work

that either of you have been working on? Aaron? I've got one I'd like to make a plug for. Sure. So WG21 is spinning up a brand new study group that I'm going to be the chair of, which is focusing on C and C++ compatibility. And so the idea is this is going to be a joint study group where C committee members are in it and C++ committee members are in it at the same time. And they can talk to one another.

And I think this is actually going to make a big improvement in terms of the intersection between C and C++ to try and ensure that the common parts stay common instead of diverging, and to also ensure that as we're adding new parts, we keep in mind how they're going to impact the other committee. And so I personally am really excited about this because this is an area that I think

is really important. It's very easy for the C committee to completely ignore the C++ committee and vice versa. And that has serious economic impact because there's 100% of C++ programmers, whether they know it or not, rely on C compatibility because our operating systems give their platform SDKs a C headers. And we all just kind of hope this all works out great. And we want to make sure that that continues to work out great in the future and work out better in the future. So I think that's going to be a really important study group for both committees. Very cool. What study group number is that? What are you up to? 20 something? SG22, which is going to drive me nuts because the parent committee is SC22. And SG21 has already been driving Aaron and me nuts because it sounds too much like WG21.

So you can't really win with the numbers. Maybe we should start using more impenetrable acronyms. What do you think? Well, I was thinking stable names. Yeah, I'm actually very happy that the C and C++ compatibility group is happening, because a lot of my papers were probably going to end up being C and C++ compatibility papers. So rather than kind of just applessly flailing between two committees and hoping that things stay synchronized, I think having that liaison group will make things a lot better for features that will appear in both like Act and Bet

and maybe Type of and upcoming paper that I might have to make U8 literals work with unsigned cars so that there's less breakage and people going from C++ 17 to 20 and from C++ in general to C, where car key doesn't exist at the moment. So yeah, that's going to be helpful for me, definitely. Very cool. Yeah, I think the study group really was born out of the fact

that when we were working on attributes in C, that was a feature that I was working on and bringing over from C++. And it became readily apparent that we need better collaboration just because of the amount of confusion between both committees as to what syntactic constructs these apply to. And I didn't realize that the language worked this way. And those sort of comments were a bit of a surprise and the drive, I guess, to improve things. When you see a little tiny corner case where you're like, I think we could make this a little bit better. And it's true, you could make it better, but then it would be completely incompatible with something in C++. And this code lives in a header file that might be compiled by either a C compiler or a C++ compiler, those sorts of problems we have to be really resistant to,

even though it might be that we could actually improve something that one committee hadn't noticed. Peter, did you have something you wanted to add? Oh, yeah, I just wanted to have a big shout out to all the tiny little papers that aren't really making any big headline improvements to the standard, but are just sort of adding little tiny convenience features here and fixing minor bugs over there. Because although we won't spend a lot of time talking about them on Foronix or Reddit or whatever, those are really the lifeblood of the standard that makes it worth doing. And of course, I have a big shout out to a nice placeholder with no name, P2169

from Corentin Jabo and Michael Park, which is just going to let you, if you want a variable, and you don't want to think of a name for it, call it underscore. And I'm really excited about this paper. This will make my life a lot easier, even though it's not exciting like executors. It's the kind of thing that really makes me want to be involved in the committee to see these kind of everyday improvements going in. The quality of life stuff, definitely. It's absolutely worth it.

It's small stuff, but's it's that it makes it just makes like the everyday coding so much better and that's those are those are you know they're they seem like small papers but they're definitely big wins kind of like over time and across the board definitely oh sure like the the fewer places i have to ever think about writing the word type name or template and I love those papers, even though they come across as seeming kind of small and insignificant. They save me time on a day-to-day basis because it just makes the language more comprehensible to me. We're getting a little bit low on time, but is there any other questions

or papers anyone wants to bring up? Shanhee, do you have any questions you might want to ask? Yeah, so, Peter, so you kind of became the assistant chair of G16. So, like, you know, you've been kind of at it for a little bit. Like, how was it like being, like, an assistant chair and, like, helping a group, like, and all that kind of stuff? Like, what is it? How does that, like, what does that process look to you? Does it involve a lot of emails?

Like, what is the workload of being an assistant chair? Like a lot of the roles within WG21, it's what you make of it. I'm just sort of filling my way into seeing how I and Tom Honoman, who's the chair of the study group,

can best share the work that needs to be done between us. I think that probably my main contribution is going to be watching little hand symbols appear in our Zoom chat for the next few meetings and making sure people get their turn to speak which's not a small thing to make sure happens some people in our in our study group are more reticent about interrupting than others are um and certainly when you've you know you've got a number of people in the study group someone's got to take notes someone's got to chair the meeting probably have a paper author presenting like having a couple more people to help the chair out with making sure that the meeting runs smoothly and everybody's gets their opinion to be

heard and we get a good consensus at the end of it i think that many of our study groups should look at getting more people involved in running them and and running them smoothly but i mean i've only been doing this for a couple of weeks so get back to me in a year's time and i'll give you a better answer see that's that's the that's the easy hook for for another appearance on this podcast you know yeah absolutely yeah and um uh aaron i mean so you i don't think there's been any meetings of the liaison group i don't think it's like fully you know hasn't fully spun up yet i don't think there's been any meetings of the Liaison Group. I don't think it hasn't fully spun up yet, I don't think, right? Yeah, correct. I'm hoping that maybe we'll have our first meeting this year still,

but given that it's starting to turn into the holiday season, we might start meeting early next year. But the hope is early, soon. Yeah, all right. Well, that's pretty cool. So the weight of responsibility and the piles of work hasn't shown up quite yet. Yeah, it's mostly been piles of work regards to thinking about how to ensure that this is a more seamless and smooth process for both committees. Because for reference, for people who don't know, the C++ committee is usually when we were meeting face to face was between two and 300 people would show up to these meetings quite frequently. And it's split off across, you know, a dozen or so

rooms that are all meeting in parallel. And by contrast, the C committee was about 15 to 20 people, and we meet in plenary at all points in time. And so the culture and the expectations of how work progresses through the committee is very different between these two and so i want to make sure that the study group considers very strongly things like um how do you how do you judge whether you have quorum can you can we have quorum if we have only c++ committee members who are in the meeting how do you judge consensus if everybody on the c committee votes yes and everybody on the c++ committee votes no but there's only three people from the c committee and there's 30 from the c++

committee so it's spending a lot of time thinking about those sort of things to make sure that the study group um it works appropriately with both committees what sort of pace does the c committee work on i mean you say it's much, much smaller, only like 15 people, but are they meeting like three times a year? How many papers are they pushing through compared to the C++ committee? So we've been working on the next edition of C, which we just learned thanks to ISO will be C23. And so our usual pace is every 10 years or so,

we put out a new feature release. And our last release was C17. So this is a little bit shorter of a tight timeframe. And C17 was just a bug fix release. So this was really our first chance to kind of open up and start doing new feature work. And so the pace has been breakneck by comparison to the C-17 pace. So we run out of time slots to discuss our papers in the C committee meetings now. So we meet virtually, just like the C++ committee does.

But we'll meet for a week at a time and doing four hours a day every day for a week. So that way we don't have eight hour long Zoom meetings for a week, which would be awful. But they realized that that wasn't enough time to get to all the papers. So we doubled the number of meetings we have in order to get the same amount of work done. So the pace has been surprisingly fast, but there've been a lot of new features that are coming down the pipeline. And then,

so I think C23 is actually going to be a really interesting addition for C where it's starting to get some great new features that we really haven't seen since 2011. It has been great having you both on the show today. Before I let you go, Aaron, where can people find you online? I'm on Twitter as Aaron Bollman. It's a private account just because I don't want people to have to necessarily contend with everything that I think. But feel free to send me a follower request, and I'm happy to follow you back, too.

Okay. And Peter, how about you? Well, I'm also on Twitter, PeterTBBrett. Lots of local politics on there, not so much C++. But if you want to chat C++, I also hang out on the HashInclude CPP Discord server. Okay. And John Heed, I'm so glad you're able to join us as a guest host today. Where can people find you online these days? So at the moment,

when I made my video, I kind of ejected from all social media, so I didn't have anywhere that anyone could find me. But you can still reach me personally at phdinthehouseofgmail.com. If you have a comment about the C standard, you can actually reach me in a more official capacity at wg14

at soasis.org. You can also find me on uh on the ash includes cvp discord i'm still kind of like rolling myself back in like twitter and discord and reddit and stuff slowly um but yeah those are all the places that you can kind of find me and and interact with me sorry it's emails boring to interact with somebody but hopefully i'll get a twitter and stuff soon and be able to you know chat it up with people more and all that other fun stuff. Okay. Well, thank you all for coming on the show today.

It was great having you. Thanks for having me. Thanks. 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 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 if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving

and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode

is provided by podcastthemes.com.