CppCast - Priorities for C++23

Episode Date: January 15, 2021

Rob and Jason are joined by Corentin Jabot. They first talk about a Visual Studio blog post on performance improvements in the 'inner build loop', and a ray tracer built into CMake. Then they talk to Corentin about his work in the C++ ISO committee on the Library Evolution Working Group and his thoughts on what could and should make it into C++23. News f(t) Faster C++ Iteration Builds Ray Tracing in pure Cmake Is Zero a Butterfly? Links What is the standard Library P2172 - What do we want from a modularized Standard Library? 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

Episode 282 of CppCast with guest Corentin Jabot, recorded January 13th, 2021. 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 for 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 discuss Visual Studio updates

and ray tracing in CMake. Then we talk to Corentin Jabot, ISO committee member. Corentin talks to us about C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing all right, Rob. How are you doing? Doing okay. Not too much news to share myself. Anything from you? Well, we've been talking about me publishing a printed version of my book, and that happened.

Oh, nice. Yesterday, I think. Yeah yeah yesterday is when i made it official so it's available now in all of the uh major amazon markets i didn't go to the like secondary markets because then your your your royalties drop drastically okay but amazon.fr.de.in.co.uk.ca.com it's all the i would say reach probably 90 percent of my potential market um and it's c++ best practices by jason turner should be pretty easy to find and now i know you you said you were thinking of getting a print copy yourself just to see what the quality and everything looked like did you wind up doing that i did end up ordering uh authors proofs of both the color and black and white version so there's actually two versions that i published because i asked my patrons and

they said that they would want color syntax highlighting and it looks like to me like a surprising number of people like maybe 60 or so are choosing the color version over the black and white version even though it costs considerably more. Um, but whatever people want. Awesome. I make the same royalty regardless. It's the cost difference in printing color books.

It's all just for the ink. Yeah. Yeah. Okay. Very cool. Well, at the top of every episode, I'd like to read a piece of feedback.

Uh, this week we got a tweet from Ben. Uh, and he actually tweeted at us and Zach Lieberman, who we add on the show last week. He wrote, I just got done listening to your interview on CppCast. I didn't know that you were the original author of Open Frameworks.

Six years ago, I used it to make a short film for my Radical Cinema Workshop class. He sent a link to it. If you're interested in seeing just another example of the type of art you can make using C++ and open frameworks, I will put this link in the show notes and it's this five minute long video and it just does some,

some cool things. It's called F of T. Yeah. I started following Zach in the open frameworks, Twitter account since then. And every now and then you just get like a really cool visual in your Twitter feed. It's neat. Yeah. Very cool. Okay, 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 cbcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Corentin Jabot. Corentin is a freelance developer and member of the C++ committee where he participates in the Unicode and Library Evolution working groups. Corentin Jebeau. Corentin is a freelance developer and member of the C++ committee where he participates in the Unicode and Library Evolution working groups. Corentin, welcome back to the show. Hello, thanks for having me. Thanks for coming on. So we have a couple news articles to discuss and then we'll start talking more about what's going on in the ISO committee, what you've been up to there lately.

Okay? Yeah, sounds good. Okay. So first thing we have is a post from the Visual C++ blog. And this is faster C++ iteration builds. And this is, I think, in update 16.7 of Visual Studio 2019. They made some pretty significant improvements with linker time improvements. And this should really improve what they call the inner loop,

you know, build the bug, edit, build the bug. And yeah, some like 2x or more improvements with generating PDB and link times and loading PDBs. So it looks like some really nice changes. This article was fun for me because on the what we did item number five.

I noticed that one too. Yeah, going from std sort over qsort was one of the things they did to improve performance of link and PDB loading time. over QSort was one of the things they did to improve performance of, of link and PDB loading time. Yeah. Yeah. I actually made this an example for a,

a, it was like why you see plus plus talk that I gave internally at a company several years ago. And I compared QSort to standard sort and QSort it's, it's impossible for it to be as efficient as standard sort because QSort has to put everything through, push everything through void pointers and function pointers. It can't inline any of it. It can't do any of the optimizations that standard sort can. Yeah. Anything else you wanted to highlight as interesting?

Jason or Corentin? That's the most interesting thing for me. Okay. Yeah. All right uh next thing we have is this blog post ray tracing in pure cmake and i saw a lot of talk about this one on the c++ subreddit i think someone tweeted it at us too uh it's amazing that you can do this that you can make a ray tracer in cmake i'm amazed that people choose to try to do these things um i don't really know what else to say it's it's crazy it's very very impressive and i understand that like the author did like that for the challenge but please don't try to do that uh please don't do that in actual production code. And please, like, the less built system code you have,

the better you are generally. So you really don't want to use all of this CMake feature and try just to have, like, the list of files. Don't make your life complicated. Don't try to be clever with CMake. I think on a kind of a practical quote-unquote note, though, is there's a pretty good primer on fixed point math in here and if you have never done fixed point math then you can learn some stuff from that don't yeah don't deploy it in

your cmake ray tracer but um but depending on what your application use cases are you might have a use case for fixed point math for some reason i didn't notice when I first read through this that the sample image that they have with the ray tracer was rendered in 7 minutes and 23 seconds, which is a lot of time to make just this little orb in a ray tracer. I'm not really sure how long this would take in a standard C++ implementation of a ray tracer, but I would imagine it would be much faster than seven minutes. If you offload to the GPU,

you can do much more complicated ray tracing real time these days. Yeah, right. But the thing is with CMake, everything in CMake is a swing, so they're actually doing math on swing and doing the conversion over and over again, which that alone is probably super slow right very interesting stuff though

okay and then the last blog post we have is on Shafik Yamour's blog and this is Zero a Butterfly which is a reference to that butterfly meme that has been really popular over the past year and it's just about how special

zero is in C++ sometimes frustratingly so I don't know, what did you two think about this article? There's lots of little details in here One of the things I learned recently is that the zero pointer, for a very long time,

I thought like zero as a pointer would be like the address zero, but that's not actually the case. The compiler will translate

zero as a pointer to whatever the new address for that system is. And for 99% of systems, that address will be zero.

But it turns out, like, in the 80s and 70s, some systems had, like, a weird address, like, bad address. And so the compiler will translate that for you automatically. And that's something I didn't know until very recently, which I find interesting. So if you pass a zero meaning null pointer on a weird architecture the compiler might actually pass that function 10. Yeah. And that's done like during compile time

or link time. I'm not sure when it's done but that's how it works. Wow. Yeah, I had no idea. It's interesting. And just remember if you're writing your own C or C++ parser, a unitary zero is an octal zero. Yeah, that thing still frustrates me. Okay, here's an aside, since I'm currently working on a parser.

Should I support the zero leading integral constant as meaning octal? Or should I require like zero little O, the letter O, as if it were hex or binary? I mean, I think that's the way it should be. But if you're writing a C++ parser, is it better to just, you know, obey the standards and do what all the other parsers would do? Not a C++ parser, just something

that just has integral literals in it. Maybe I would like to use the letter 0. Don't do C++. Don't do C++. Alright. Thanks. Okay. Well, Corentin,

let's start talking a little bit about what you've been up to lately. You wrote this long blog post back in September about the standard library and the ISO committee and, you know, how it has relatively scarce time and resources. And yeah, I thought it was very interesting blog post i definitely didn't find myself arguing with anything you wrote there um but yeah you want to tell us a little more about your thoughts there and and how well you think iso has been handling virtual meetings over the past year yeah it's like really something that i've been on my mind a lot recently. So what happened actually is that in the early,

like near like 2009 and the year after, like around the time of like going native, I remember people in the committee, I wasn't in the committee at the time, but when you look at like conferences and like the committee panel or whatever, every single time, every single like video you could find, like committee member would say. Every single time, every single, like, video you could find, like, committee member would say, write a paper to every single question that you ask them, right? Like, why is C++ like that? And they would say, write a paper.

And at the time, there were, like, maybe, like, 50 committee members. And they were, like, so it was, like, not a small committee, but, like, not a big committee either. And they, like, I guess, wanted more people and more participation and uh they couldn't get all the work themselves so they were trying to like get more people and over the past like few years they really got what they wanted right like since i'm like since i am like at the committee maybe like the number of like participation that like maybe a factor of three like three times as many people since I joined in 2018 or something. And it's been growing.

And now we have 200 people participating in committee meetings when we meet face-to-face. And at the peak of the 2020 cycle, when people really want to get things in 2020, we're mailing with 200 people. And there's like 20 things in 2020 we're like mailing with 200 paper and like there's like a defined pipeline in the committee and we have been trying to find solution to make like things smoother and things like that but the fact is like there are like more papers than we can deal with and so um it used to be that the committee could like deal with

every single paper that they had and say yes to everything because the committee hardly said no to a paper. Maybe if you want to add garbage collector to C++ we will tell you to go away. But most of the time... They're trying to remove the garbage collector.

But most of the time people write good paper and the committee wants to add this feature and things like that. But we're stretching the pipeline a bit thin, and the committee can't deal with everything that it wants to do. And one of the things that we've been doing is adding the library and evolution incubator group, which are pre-reviewed papers to make sure they like at least presentable for to move forward And I like ton of study group and like I think they're like 22 or 23 study group at this point The last one being the C and C++ liaison study group

But the pipeline is the same is that you have all these study group things, and then it has to go through library evolution or language evolution, and then to wording. And wording is a very slow pipeline because it's really hard to do wording, and there is a very small number of people in the committee that are actually able to review wording. I think there are maybe 10 people that are able to review library wording properly, and same thing for core. And even for simple proposal, doing wording for this thing is very slow.

And so a few things happened in the last year. One of them is that we have been very enthusiastic about C++20. And Library Evolution has approved a lot of design for C++20. Like in Belfast and in Prague, a lot of last-minute small paper has been approved. But Library Vording, we didn't have time to review that wording. And so they didn't make it to 20. And there's a pipeline of 60 papers that Library Vording needs to look at. And that's at the start of C papers that library boardings need to look at. And that's

at the start of C++20, right? Right. And that was the first thing. And then I think we were already super happy with C++20 and very optimistic and say that we were doing a ton of stuff for C++23. But then realizing that C++23 is actually in

a year, because it's early 21, and we need to be the equivalent of feature phrase in basically a year, right? Right. And so it's very short. We have less than three years to do a version of C++, so it's a very short time. And on top of that, there is the COVID situation, which like closed things dramatically for everyone and so like we really have to find a way to prioritize things and decide on priority which is not something the committee was really doing like five years ago like they had like time to do everything but now

it's really we have to do something and like the thing we are not doing, get depredated, right? So we have to select things. And it's not something that, it's something we are still learning to do, right? As committee. So that basically what's happening right now as a committee is trying to like find better ways to manage like the amount of work that we can do. Versus the amount of work that we can do versus the amount of work that we want to do. Because there is a lot of enthusiasm in the committee and all of the study groups. I'm in the Unicode study group and I want to do Unicode things and people are working on linear

algebra, networking, graphics, all of this kind of thing. Like, there's also, like, a massive, like, numeric test, and all of these things that we want to do, and our time is, like, super limited, right? Right. So that's basically where the committee is right now, which is, like, it's both,

like, a good place to be, because that means, like, both the committee and C++ and the community is very much alive and doing things, but at the same time it's complicated to manage that amount of work. So basically, where are we at?

So you are describing it as kind of a pipeline problem and I have no membership on the committee, know you talked about how the committee itself expanded so much uh i guess is the issue just that all these new members none of them are capable of going on the wording team like is that kind of one of the main issues yeah i don't know like it's like there's even if you're like more people in the wording team you see like one

wording team so it's like you have all these 2d group right like they're like 22 to the group none of them are active but like there may be like 10 active to the group and then they're like to design to the group and to wording to the group and the wording is like the slowest part and you kind of want to be slow because that's like the step where you want to make sure that everything is doing what it says and there are no bugs that are introduced by anything. So you really want the best C++ expert

that you can in that group, both in terms of just writing the wording or reviewing the wording, but also make sure that there are no issues with the design that other groups didn't found. So it's a bit challenging to scale that group in any form. But then the question that I'm starting to ask myself is, is all of the things that the committee is doing, does that warrant having a wording specification

and going through that very long, arduous and expensive process of standardization, right? And I think that's a very interesting question. Like what's, for example, the point of having a networking library within the standard, and cannot it be just a package on the side or something you find the side or something

you find on github or something like that um right yeah so um yeah and i definitely picked that up in your blog post that you seem to be of the opinion that uh some of these libraries like networking that are being standardized um maybe don't belong in the standard. I mean, is that a common opinion? Do you think there's a chance that networking is not going to be added? Or are you kind of... So I want to be clear, right, that

everything I say is my opinion. There's no committee. There's no committee opinion until we take a vote and it ends up in the standard. There's no committee opinion, right? Until we take a vote and it ends up in the standard, there's no committee opinion. I know people have complained because contracts didn't make it into 20, and people are like,

but you said there would be contracts into 20, but the fact is until there is a published standard, nobody really knows what will be into 20 or 23. So we try to have priorities and plans, and there's a bold plan for C++ 23 that we voted uh less like before we knew there would be a pandemic so that plan is like a bit ambitious. Uh but just looking at the amount of work that would need to be done for networking to be to go through just like just just in terms of design knowing that that we have one year worth of meetings, we meet basically

one and a half hour a week per group, which is already a lot for some people. So that basically we have 60, just for library features, we have 60-70 hours before the end of C++ 23. And that is a very short amount of time for the things that we want to do. And so I personally hope that we don't spend too much time on networking because there are things that maybe better use of committee time knowing that we have a limited amount of time. Because the time we spend on networking, we are not spending it on anything else.

So it's also like we have to choose, do we want networking or do we want 10 other smaller features? Which is a bit unfair for people who really want networking or people working on networking. But we'll see how that goes. I'm reminded of the graphics proposal that

had strong support for a while and then a slightly different group of people voted on it and then it was removed from the standard right? It was never in the standard Oh okay But there was like a not a pl plenary vote, but like a vote with

the entire committee meeting that said we didn't think that was like a priority for C++ for graphics, but I think people are still like working on it and doing some work there. So, but it's difficult because like even if like there's like a study group doing something, it doesn't mean that the rest of the committee will be happy with the design. Right. So, which is also, like, a problem with networking because, like, there are, like, a small amount of people working on networking for, like, a decade. And it's really hard for these people, like, they want to get results and, like, have something for their work. And, like, it's not clear that the committee will say, okay, we will get this done.

So you can spend 10 years working on paper, and the committee will say no, either because it doesn't like the paper or because it doesn't think that the paper is a priority for C++. But the committee, as a whole, actually voted to prioritize networking. So it's not like the highest priority. The thing we are really trying to focus on is executor.

And we are really trying to make sure that planned into 2020 and spending, basically we spent the last six months mostly talking with executor in library evolution. And when executor are done we probably look at networking uh but if we look at networking we're not looking at something else so i can uh like my personal hope is that we put networking aside uh when we realize that even if we look at it we won't have time to to get it done so there's a you said you know spend a decade working on on the networking proposal. And I think for the people who are putting this time in,

the very real and understandable chance of burnout if you put 10, 11 years of your time in and then the committee says, we're not going to accept this. And you're just like, all right, whatever, I'm out of here. Yeah, yeah. That's definitely something that happens actually in a lot of the time, right?

But all of these big proposals take a very, very long time. So if you said that you would set aside networking because it's big and there's other priorities, what priorities would you want to focus on for C++23? That's a good question. So, of course, the committee is really, as I said, focusing on executor and trying to get things done with some form of core routine support

for the standard library. But also, a thing we are also trying to do is actually complement things that we did in C++20. So for example, in C++20 there is ranges, but if you look at what is in ranges in C++20, there is a very limited selection of view compared to what you can find in ranges v3,

for example. And so there is a group of people that is trying to get like a few more views like like zip and fold and this kind of thing in in 23 we have spent a few meetings recently doing improvement to suit format and so and just like just trying to like complement c++ 20 like could20 could take us the remaining of the meetings that we have, like adding small features. If you look at how people use C++, you realize that small features are more used by most people than big things like networking. Like a stupid example is that one of the very few things that we voted to put in 23 is a content function for string, which is like

a very small proposal, but like it will be used by probably like a lot of people. So it's like, it's not like anything like tech committee time to get that through. So it's like total maybe like a few like a few hours to discuss the name and to discuss the wording. But it's super useful to have this small feature as quality of improvement. Yeah, I needed that function about five times on Friday alone, actually. Yeah, and there's another proposal that is in the queue

that is start with and with first string. I think we have like that first string view, but we don't have that first string. So that's kind of small thing that we are trying to get done. And then the thing that I would like personally like see progress on is like there have been like conversation for like as long as I've been like a committee member and I think it's like decade of conversation about like error management and we don't really like there are people that will never use exception and there are people that

think we should use exception for everything and like it's it's it has been like an issue so I would like to see like progress in that area in some form. They're like, it's too expected that it's in a TS for, that has been in a TS for a few years, and maybe I would like to see progress on that. It's very unlikely. But this kind of thing, I would like to see progress on a paper that was written by Arthur Dwyer,

which is like copy in terms of move plus disrupt, something like that, that basically provides something like realloc for a vector. When you move a vector, you don't have to individually move each element, so it's a lot more efficient because you can implement your vector move in terms of just one memcpy.

And so you get easily 30% faster operation when you're trying to do a pushback on a vector that doesn't have enough capacity because you can just memcpy all the elements at once. It's somewhere in the queue of things the committee has to do, but I think the author dropped the paper on the floor because they don't think they have enough implementation experience. But it's this kind of things that are not really like, that doesn't seem like a big feature,

but actually improve the performance of C++ or make the C++ more freestanding, friendly, or improve accession. This kind of corner of the language that the committee agrees that we need to find solutions about, but we really don't. One other thing we are really struggling with is executor. Executor is basically a bunch of customization points, and the entire committee seems to agree that there's an issue with customization points

and how we declare them and how we defeat IDL. But it's very difficult to convince someone to actually put work into finding solutions to improve the issue with IDL and finding ways to write customization points. And so there's this proposal. I don't know if you saw, a proposal for TagInvoke, which is a library feature to make writing customization points easier,

but it's still very much a complicated feature to use. And I would like to see language feature to do that kind of thing. So, and of course, I think we're trying to make progress on reflection, but as I said, we only have like a year and it's very unlikely that reflection can make progress in like a year does it ever happen that in library evolution you say you know what this is an interesting library feature

but really we think it should be a language feature and push it over to the like language evolution group or whatever yeah we like we tried but it's it's it's interesting because like if you look at i don't know that was long before my time it might be like before c++ 11 i don't remember but it used to be that there was only one pipeline right there was only like language language library was like one single room, and then there were wording. So it used to be just two rooms.

And now it's like 20 rooms. But now it's like separated. And I think the fact that it's two rooms are separated influence the design of things that we do. Because, for example, people in library might think that it's easier to get a library feature done than a language feature done. So if library really wants something to be done in 23,

they will probably try to do it as a library feature rather than to try to convince someone from language to do something in time for library to be able to use it. Like there are these things that says that the output of an organization reflects the structure of that organization, and to some extent the fact that library and language evolution are separate is kind of somewhat reflected, even if the two groups talk and people go to the two-group and so forth. But for someone that is used to write library features, it's not that easy to write a language proposal. There's a much higher standard to write a library proposal.

Even if you want to propose an implementation, writing an implementation for a language feature is much harder, right? Because you have to modify a compiler whether a library feature, you can just, like, act together something in Godbolt in an afternoon, right? So...

So... Yeah. And that it didn't break existing code, right, if it's a language feature. Yeah. So I think there was, at some point, like, a paper that was, was like a list of things that Labo Evolution wanted from Language Evolution.

And one of the things was please fix ADL because it's an issue. But at the same time, like fixing ADL is something that nobody, like everybody would like to do, but nobody really knows how we would even start tackling that issue. I think like Herbstetter has a paper for IDL that has been in the works for like two decades at this point. 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's description. One thing I'm curious about is, you know, you're saying that in library evolution, you're spending a lot of time on executors right now when you know executors hopefully does make it in past library revolution is there a vote to decide you know what you focus on afterwards because i know you're saying you know you prefer to work on some of these smaller features whereas some other people might prefer to work on networking how is that sort of thing decided so what what happened is that um there was a paper that was voted on in Prague by the entire committee, which is a bold plan for C++23. And in that paper, it says that we will make progress on executor, networking, coroutine, standard library module, and we'll try to make progress on reflection. And so because the committee approves that paper in plenary

is somewhat binding. So unless someone else manages to get the committee to work on changing the priority, we will keep this priority working until C++23 ships. But at the same time, we also try to, in between the big executor discussion, we try to work on smaller paper.

And the other thing is, library and core are currently doing... So they have to do wording, but they also have to do issue processing. And because we shipped C++20 recently, and every implementer is currently trying to implement C++20, a lot of issues are made by implementers. So a lot of time is also spent on fixing issues,

and sometimes it has to go back to evolution. How do we want to fix that issue? lot of time is also spent on fixing issues and sometimes it has to go back to evolution how do we want to fix that issue so uh because c++ 20 was a very large release right so uh but yes the binding plan for the committee is to make progress on networking uh we can't we can't like uh like vote on like shipping networking in 23 because like uh it's not ready until it's ready, right? But we voted to make progress on it. I'm not happy with that, but that's actually the opinion of the committee by finding votes that networking should be work on.

So, yeah. I also wanted to ask about this paper you wrote, what do we want from a modulized standard library? It's something I think we've talked about on the show before. Yes, we have modules now, but how much use can we get out of

modules when the standard library isn't modularized? But you seem to think that we aren't going to get that much out of modularizing it. Is that right? So, like, there are, like, two... How do I start? Like, there are, like, two different kind of, basically, modules

that we added for, like, compatibility with older standards. So one is the, like, module that people talk about mostly, which is like your module and you export what you want and you compile it as a module and you can import it with the import module name syntax, right? One is the other form of module, and with that you have partition and all of these things that are related to module, right?

Like interface partition, implementation partition, private partition, all of these things. Sorry, not partition, but like module interface, module implementation, and module partitions. But the simpler kind of module is just take an header and basically do the equivalent of a pre-compilation, a pre-compiled header, right? And so you can actually import header in C++20. And if that header has been like pre-compiled, it will be like imported, like it will be like a pre-compiled header with all the, you get all, you don You don't get the same symbol isolation of not seeing what's not been exported, but you get the same compilation speed because it has been precompiled

and the compiler doesn't have to do the parsing over and over again. So if your concern is using module for compilation speed, which I think is what most people want, you can use this module header unit. And if the compiler supports that, in C++20, we explicitly say that every single standard header can be imported. So what you can do is pre-compile all single standard header can be imported. So what you can do is precompile all your standard headers,

and then when you can type import, angle brackets, vector, it will use this kind of precompiled header unit kind of module, right? And that's one thing you can do. And then we go even further is that if the compiler knows that vector is an importable header unit, it can replace every single like include vector by import vector and import the pre-compiled header unit instead. And so if you have like a compatible C++20, you don't need C++23, right? So in C++20, if your compiler and your build system let you do that, your standard library will always be

very fast to include. And I tried to do some benchmark with the compiler I could with Clang, and it's really, really fast, right? You can import the entire standard library, like all the header of the standard library in like a tenth of a second. And so you get like most of the benefits of compilation speed for module that way.

And on the other side, all of the other benefits you get from module in terms of symbol isolation and things like that, it is not clear that you can get that from the standard library, notably because of ABI concern. So the standard library implementer will not necessarily want to have the entire standard library in a module directly. So they will probably keep the standard library as it is today, and the standard library module will just be exporting everything. So the only thing that it would change, basically, is the syntax of how you import a standard library feature.

And behind the scenes, it would behave like if you use the module, but it would actually just transitively import an header. So there are not a lot of benefits from doing that in my point of view. And the other thing is that we don't... I think module is one of these features that we understand how it works from just the design of the feature, but it will take maybe a decade for the C++ community to understand what's the best practice of using modules. And one of the things we really don't know in the community, and it's actually really hard to get data on that, is what's a good size for a module.

One of the things we talk about is making a huge std module, right, just and put everything in it. And would that be actually reasonably fast to compile or not? And we don't really know. Some people want, like, really small module, which for me, like, make no sense whatsoever in terms of, like, compile speed. Or do we want to have, like, modules that are, like, the same size as a standard reader currently?

Things like that, right? So I think we don't have enough information of actually being able to really inform the design of what we want for modules in the standard library. And I don't feel that it's something that you actually need to use modules in C++20. My personal expectation is that people will start to use module. So first of all, there needs to be like built system support, which might take like a few years. And then I think people will start to use module

in their new projects. And for legacy code, they will keep using this importable header unit transparently. And like header unit was really designed for, like it was a design goal of people originally to not have to rewrite all their code for module. So that's why we're like this kind of flag

to different model for legacy support. So for new projects like use module and you don't need like standard library support to do that at all. And for, if you want like better compile speed out of your like standard header, please ask your implementer to support that at all. And if you want better compile speed out of your standard header, please ask your implementer to support that feature

and your build system your build system to support that feature. I will say, I don't remember who it was we had on recently, Rob, who said they thought it would be that modules is basically

a C++23 feature because that's when we'll actually be using modules. Corentin, you're more pessimistic than they are saying, what did you say, a decade or so before we really know how modules should be used? It's like, you know, like, but I feel like we are still, we are still like having debate about like how to use auto in C++, right?

So it's not that people will start using module in a decade. They will start with a decade, like maybe three years is a reasonable assumption, but then it takes a long time to actually like, you have to deploy module for like a few years

and basically look at what went right and wrong before you start to understand really the back practice of that feature. So like we understand how module works, but we don't know what the big practice of that feature. So like we understand how modules work, but we don't know what the best practices for modules are. And that takes, basically what it takes is like very large team

deploying modules in very large projects and see what kind of benefits they get from that, how they can teach modules, how they can deploy modules, how they kind of benefit they get from using module at large scale, what's the impact in regard to distributed build system, because that was like a huge point of contention, and we really don't know what the performance of module are within a distributed build system.

So all of this kind of question is something that you actually need to use the feature for a long time before say, okay, that's, we should like use modules that are like this number of classes of this number of symbol of this size and things like that. Right. But yeah, I think like three years is like a good, maybe a good assumption. Maybe that's optimistic. I don't know. It depends on how fast people can update their build system once the build system supports that. I don't think anyone, basically no one, no one will use module until CMake has very good module support.

And then when CMake starts to have module support, it will back people to start to use them in new projects. That's probably a good point, yeah. Yeah. That build system we all love to hate and use anyhow, and yeah. Yeah. Make ray tracers out of. Yeah. Yeah, right.

You mentioned earlier that there was this binding paper about the direction of C++23 that was, you know, talked about the direction of focusing++23 that was talked about the direction of focusing on executors and networking. If you were to write your own version of that paper, what would

you set the direction of C++23 as? What do you think would be the most important features to focus on? I still don't know if I like the idea of giving priorities. It's really hard for the committee to give priorities to begin with because everything the committee does on a volunteer basis, nobody is paid to do committee work,

or they might be paid by their company to attend a meeting or whatever, but the committee itself cannot give anyone. The committee cannot say we will do that because then you have to ask someone to do it the committee itself cannot give anyone the committee cannot say we will do that because like then you like to have to ask someone to do it and that someone will like want to be paid or whatever so the committee cannot like give order to anyone right so so priority like the priorities that are in that plan are said because they're like paper for this feature already so the priority is really saying we we are looking at that paper that

someone already committed they wanted to work on. And for example, that's why ranges are not mentioned in that paper because at the time that paper was written there were no paper to say we want to do that for ranges in C++ 23.

So for me, I don't know if trying to allow these priorities works really well in the way the committee is working on being this on a voluntary basis and working as what is ready and what not. But in terms of the absolute priority, but I think the entire committee agrees with that, is reflection. Not only because reflection is useful and it's fun for people and people have been asking for reflection for very long, but also once you get reflection, you can write a lot of papers that are proposed,

either a library feature or a language feature, whatever can be implemented on top of reflection or with reflection. And so once you have reflection, you can remove a lot of language feature proposal because you can do the same thing with reflection. So I think that's a very big priority for C++, but at the same time, it's a very large chunk of work.

And there was recently, I think we talked about it in the show last year, this paper from And Sutton, which is a 26-page paper that lays a plan for reflection and that six or more years of work. And we don't yet know if we can like find a subset of that work for 23 in the amount of time that Evolution has. And I think like by the time we get like Executor done in library, like C++23 at that point will basically like be near completion. Like we will be done with that probably this summer, and then it's not that much time to do actually a ton of work. And it's super annoying, right?

Because at some point in June last year, I think I couldn't focus on anything else, so I wrote like 10 papers because that's what I do. And it's all things that I think would be useful to have in C++, and I think they're good features, that's why I propose them, right? But then you start to think, okay, my work is actually more priority than everything else we have on our plate, and it's not, right? So a lot of the things I'm working on will certainly not make it into 2023 because it's not priority, right?

And I think a lot of people are in this situation where they have a very good idea for C++, but we just simply don't have time to look at that in the time that we have. Yeah, it's what it is. But for things like networking, you can use Azure today. And that's what I'm trying to explain to people, right? Azure is a superset of the networking TS that you can use today, and it's a data-only, so it takes like five minutes to a two-year system.

So if we don't have networking in C++ into 3, you are really not missing anything. Right, and if you're using Conan or something already, then you can pretty much just type a few buttons, and you have Azure ready to go. Yeah, exactly, right. And you talked about networking recently with Robert, I think. And like I said, there are versions of Azure that depends on Boots,

but there's also a standalone version of Azure, which is the only... And the other thing I haven't mentioned is that I have a feeling that implementer... Once the feature is in the standard, it's just the beginning, right? It has to be implemented in, like, three compilers. And C++20 was a big chunk of work for implementer.

And it will be, like, quite a long time before, like, all three or four major implementations of C++20 took four months. And so asking these people to, on top of that, implement networking is a bit much. Yeah. They're like implementations that still don't implement C++ 17. Right. Yes.

Because it took the committee a fairly short amount of time to say, we want a function that converts a string to a double without string exception that you can do that in like one hour and like four years later people are still trying to find ways to implement that That's two cars and from cars

or whatever, right? Which I think Visual Studios might be the only one with an implementation still I think so It took like two years to do that basically Which I think Visual Studios might be the only one with an implementation still. I think so. It took like two years to do that, basically. He called it his final boss, I believe, in a Twitter thread. I think it did a very great CppCon talk last year to explain why it was so complicated.

The other very big feature that has not really been implemented everywhere except in Microsoft is the parallel algorithm. And then again, a feature that is very easy for the committee to do, relatively speaking. It's not a huge amount of work for the committee to do that, although we had to make sure that it was actually implementable. But then actually doing that work has taken a very long time to Microsoft. And I think GCC and Leapsy Plus are still struggling to get that done. And I know that Intel had to give GCC and Clang the permission to use the parallel standard libraries that they had and things like that. Yeah, GCC has, just for the record, officially adopted Intel's implementation.

Oh. So you have it with GCC and you have to link with dash LTBB to actually get it to work. Oh, yeah. So they don't ship the library itself. You have to, yeah. Yeah. So, yeah. So, yeah. Well, those are interesting points.

So given the amount of work that it takes to add something to the standard, we have to ask, is it really necessary to have that thing in the standard? Which is very different from what we did before which was, is that useful? The answer to is that useful is

basically universally yes. Right. Everything is useful to someone, but it's like, it's no longer sufficient to get something in 20, in C++. And we have like to spend a lot amount of time like doing prioritization, which we didn't do before. So we have like a list of paper in flight

and we like to say, okay, do we want having a string content function, but do we want it more than having optional modatic or things like that? So it's a really difficult thing to do, especially for paper author when they find that their paper is in the bottom of the backlog, which might as well mean that we might look at them in a few years. Okay. Well, yeah, makes sense. It was great having you on the show again, Corentin.

Is there anything else you want to plug or grow before we let you go? No, I think that's it. It was really great talking to you both. Yeah, great having you on again. Awesome. Thanks. Thanks so much for listening in as we chat about C++. We'd love, great having you on again. Awesome. 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 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 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 was provided by podcastthemes.com.