CppCast - Prague Trip Report

Episode Date: February 21, 2020

Rob and Jason are joined by Hana Dusikova from Avast. They talk about the final changes that went into the C++20 draft which should become the official new standard in 3 or 4 months. They also discuss the direction of C++23 and some of the papers that were proposed in Prague. News C++20 is here! 2020-02 Prague ISO C++ Committee Trip Report — 🎉 C++20 is Done! Links To boldly suggest an overall plan for C++23 ABI - Now or Never Epochs: a backward-compatible language evolution mechanism std::embed Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license Read the article "Zero, one, two, Freddy's coming for you" about a typical pattern of typos related to the usage of numbers 0, 1, 2

Thank you. In this episode, we discuss news from the Prague ISO meeting. We're joined by Hanna Duskova from Avast, who hosted the meeting. Hanna tells us about the final changes going into C++20 and some early work by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. How are you doing? I'm doing just fine. I'm excited for this interview.

Yes. Do you have anything you want to share before we get started? No, not at the moment. Okay. Well, at the top of every episode, I'd like to read a piece of feedback. And this one was a comment on Reddit from Patrick about last week's episode saying, this was a really great episode. Thanks for consistently making my commute better, CppCast.

So, yeah. Thank you, Patrick. Thanks for listening making my commute better, CppCast. So, yeah, thank you, Patrick. Thanks for listening. Yeah, well, I'm glad. Yeah. 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 cppcast.com. And don't forget to leave us a review on iTunes

or subscribe on YouTube. Joining us today is Hanna Dusikova. Hanna is working as a senior researcher in Avast Software. She is the author of CTRE, the Compile Time Regular Expressions Library, chair of SG7, which is the study group for compile time programming, and Czech national body representative in WG21, the ISO C++ committee. Hanna, welcome back to the show. Hi, it's good to be back. Yeah, so we go ahead, Jason. No, I was just gonna say you've, it's good to be back. Yeah, so we... Go ahead, Jason.

No, I was just going to say you've got a lot going on with the Standards Committee, but that is the entire point of this interview, so I'm not going to ask any questions about it at the moment. Yeah, so we definitely want to go over the trip report that Bryce posted to Reddit and go over your personal thoughts after the C++20 meeting in Prague. But before we do, I did want to comment on this video that went out. C++20 is here, and this was made by Bryce and Connor Hoekstra. And it looks like they did a whole bunch of interviews with different members of the ISO body.

It was pretty fun to watch. The way you just introduced that, I realized Bryce has reached the point of just being a single-name person like Madonna or something. Sorry. Yeah, Bryce Adelstein Lelbach. A few years ago, I learned it. Yeah. Yeah, so the video is like, what, eight or nine minutes long.

It's on YouTube, on Connor Hoekstra's channel. You should definitely go check it out. We'll put a link in the show notes. You guys have anything else you wanted to comment on with that? No, it's just kind of fun. Okay. Yeah, fun video. Okay, well, as we said, we have you here because you were at the recent ISO meeting in Prague.

And before we get started on all the news that's in this trip report, maybe we should comment about how it was actually your company, Avast, that hosted this ISO meeting. And I was kind of wondering, you know, you're already the chair of the SG7. Was there a whole bunch of extra work on you in having your company run this meeting? Con uh my company it was actually easy we are proud to do it but organizing it it was really stressful for a few last months because uh i think i shouldn't say but some members of committee cannot read so uh originally it was like 150 people signed up, and that week it was like 233 people on the meeting. So it's a logistical nightmare. Wow, so 150 people signed up, but 80 extra people actually showed up.

Yeah, but we had some buffer, so it was kind of okay, but it was logistically hard. And originally, when we discussed it with Herb, I was asked for 160 people and six rooms, and now we needed nine rooms, and it's fun. Wow. I wonder now what the next one's going to look like, if it's going to continue to grow like this or not. The next meeting will be in Varna, and we expect a little bit less people, because

it's not a release meeting. There is always more people on a release meeting than on an ordinary meeting, but the growth looks exponential. Yeah, so this was the most, the largest C++ committee meeting ever. There are 252 people, according to the Sherpa report.

That's huge. Yeah. And I saw, correct me if I'm misquoting you, but I think on Twitter you said something like, it's like having a wedding. You invite all of your friends, but then you're too stressed out to spend time with them. Yeah, that's 100% correct.

I was so stressed, I missed like half of the week. Oh, that is unfortunate. You're kind of like a conference organizer, right? Yeah, it's like conference. Actually, original meeting C++ was 150 people. Yeah. Yeah, at 230, that's bigger than the last three conferences I went to or something like that. No, not quite.

But still. still yeah it's quite big okay well hopefully you did get a chance to sit in on some of the committee uh meetings so we can uh talk about all the different work that went into uh yeah i spent some time in at least the group that you chaired anyhow yeah yeah i i was there yeah okay okay so uh yeah let's start talking about um what you know happened at this meeting this was the last meeting for c++ 20 i believe the the draft is final all the national body comments were resolved is that right hannah yeah uh this was actually a release meeting. We finished the C++20, and the international standard draft, DIS,

is going to ISO, and now all national bodies will vote on it, and if we don't get any negative votes, it will be expedited on a quicker path, and it will be released in three or four months, officially. So it's hypothetically possible that some international body could still block it somehow?

Yeah, it's possible, but all national bodies of subcommittee 22, at least majority of them, were in the room when it was voted in, so it should be a okay good very good so i expect it will be recently or four months and it's not listed in this trip report at all but i think this is the first meeting that the israeli national body attended yeah yeah and

so i just thought i'd point that out they had a, I think, four or five people, it looked like, who went. Yeah, I think it was last year in Core C++ when Bryce gave them a lightning talk about how to become a national body, so it was quite quick. That's awesome. Yeah, we can blame Bryce for the size of the committee. Yeah. So let's talk a little bit about what... Oh, I'm sorry. Go ahead, Hanna.

I actually became a Czech national body also because of Bryce pushed me. So thank you, Bryce. So this is the first standard that the Czech national body will be voting on as well? Yes. Okay. Very cool. Well, let's talk a little bit about what did change in this C++20 draft. There's just a couple of bullet points here. The first one is improved context-sensitive recognition of module and import to make it easier

for non-compiler tools such as build systems to determine dependencies. Is there too much to comment on with this one? It seems to make sense. I just kind of skimmed over the paper. You should skip modules because I skip most of the discussion on modules. Okay.

I keep waiting for a compiler that 100% supports it so I know what I'm looking at. That's where I am with modules. They are kind of complicated, but I think it should be usable and nice. Okay. Well, it definitely looks like this is a good change for build tools that want to implement modules. Okay. Several new range-ified algorithms were added.

I've seen a bunch of complaints about algorithms missing from ranges in the first standard. So I don't know if this relieves any of those complaints. I'm not sure, because at this meeting, we only did small changes in National Body Command resolutions. So there shouldn't be any significant changes on this meeting. There wasn't, no.

So if you're missing any algorithms, probably you need to wait to 23. Yeah, that's what I've heard mostly is, yeah,

you have to wait. Yeah. Unfortunately, you cannot get everything. Some things are hard to implement. For example,

zip algorithm. And I was on the meeting, it was on the last meeting, I think, and they found some issues with it so they decided not to go forward with it

okay they probably need some changes in std pair or something so std pair is not complicated enough yet it needs some more additions yeah actually it's really hard

to keep, to be updated with all progress because there are nine rooms in parallel. Right.

You have no chance to like, to know about everything. So you just hope that the right people are in the

room and you trust them. Browsing through that paper, it looks like some of the changes are algorithms that were first created in C++20 that got overlooked for being added to ranges, like shift left and shift right.

Yeah, it's possible. I'm looking at that paper now, too. Okay. Only a couple more things for changes and additions to C++20. The other one added ranges s-size, so that's signed size in addition to the existing std-size. Yeah, making that more consistent.

s-size is... Go ahead, sorry. It's just making it more consistent with the rest of the libraries. We have std-size and std-size, so we also want std-range's size and s- s size, so we also want std range s size and s size. Right. Okay.

And then another module-related thing, redefining the meaning of static and inline in module interfaces. So I don't know too much about this one. I didn't even click on that. I didn't. Okay. So one of the other papers that I did read through, which I found to be very exciting, I think we may have talked about previously on the show when we saw the paper originally submitted, Jason, was this one, Adopting a Plan for C++23.

The paper is 0592, and it's a boldly suggest an overall plan for C++23. And it looks like this was approved. So we at least should have some idea of what features we will get assuming this plan is followed through with C++23. Right, Hanna? Yeah, this plan is mostly to set priorities for the committee. What we should spend time and what we should spend less time. So it's more than wishlist, but something can change. For example, if we found some problem, we can postpone something.

And if we found that we are already with something, we can push something forward. For example, some people, including me, wish for Reflection in 23. Hope. Yeah, so the list of features here that that are you know on this wish list for c++ 23 are library support for coroutines a modular standard library executors networking and then also uh reflection pattern matching and contracts yeah but for uh last three we don't have any particular shipping vehicle so uh when we will be there, maybe we will release it.

What does that mean by no particular ship vehicle? Like there's no TS for it yet? No, Reflection already has TAs, but we are not sure if it will be 23 or 26. Okay. That's what I have to say. Yeah. But hope for the best and we will get all of them but

we will see and contracts again, Redux part 2 contracts the return discussion in colon was really heavy and I was in the room and it was a lot of strong words yeah but I hope we will move with the contracts forward because they can be useful I was in the room and it was lots of strong words. Yeah, but I hope we will move with the contracts forward

because they can be useful for many things. We need to decide for what things. I think it's worth, since you said that there were lots of strong words with contracts, it's worth at this moment scrolling down to the first comment on the Reddit discussion, if you were so inclined to

read that. Sorry, not the first comment, but the second one discussion if you were so inclined to read that or sorry not the first comment but the second one because the first one's from bryce uh basically saying that they were overwhelmed with how friendly everyone was at the committee so we talk about this fighting and these discussions and how people are you know very strongly opinionated and whatever, but apparently it's still a very friendly atmosphere. It depends on meeting, I think. And the committee is trying to do the best. And this meeting was more relaxed, mostly because it was a release meeting,

so there wasn't expected any big changes. It was not near deadline, like in Cologne. There was like, everyone wants to push their stuff into 2020, because it was deadline meeting. This was Belfast and Prague was National Body Resolution meeting, so it was

less controversial. And also, when we choose the venue for the Prague meeting, I ask for venue with windows. People can look outside and watch. There is a world outside. That venue

was on a hill or something? So you actually had a view? Yeah, there was a nice view to the city. So people could see daylight and it was much relaxing to everybody. That does seem helpful yeah actually at the beginning of the meeting titus uh approached me and thank you thank you i have window in my

room i'd like to always request that also when i'm teaching like a room that's like in the basement with no windows it doesn't help anyone's mood yeah yeah so is there anything else uh you wanted to talk about with c++ 20 hannah or should we start talking about you know some of the other discussions that went on uh you know post c++ 20 I think I will quote Tony uh c c++ is done perfect it's great uh so one thing we've talked about recently and you just mentioned uh titus was this abi stability paper that he posted and we talked about it with him on the show a couple months back and uh that discussion did occur um at this meeting were you able to attend that, Hanna? Yeah, I was in the room. So how did that go?

Interesting. People argued for ABI breaking and against, because you can see reasoning from both sides. For example, if you want performance, and if you are able to recompile everything you obviously want to be able to break abi for example i can understand why uh companies like google wants to break the abi because they can and they just recompile everything can gain a few percent of performance and it will save them some money but also some companies cannot do that. It wasn't in the discussion,

but, for example, Sony with PlayStation, they need to keep ABI stable so you can play old games on your PlayStation. And if we break the ABI, we will change ABI of C++ and they will stuck on old version

or with some fork and you don't want to fork C++. Because in a moment, when we break ABI, there will probably be a new group which will maintain old C++ for compatibility reason. So there is arguments for breaking and against. I'm not sure where I'm standing. So I was mostly just listening and vote neutral.

That's an interesting point about PlayStation. I hadn't considered that before. I'm not sure where I'm standing. So I was just listening and vote neutral. That's an interesting point about PlayStation. I hadn't considered that before. But yeah, if you have an old PlayStation 3 disc and you want to be able to play it on PlayStation 4... You cannot do that, by the way. Oh, you can't? Okay. But that type of situation is what you're talking about with API compatibility, right?

Yeah, yeah. Or even if you have a game that's released next year with a new compiler for the PlayStation 4, then you'd have to ship a whole new set of libraries also to go with it, I guess. Yeah. But there's also reasoning that there are companies which already went bankrupt,

but people are still using libraries from them in binary form. And you cannot recompile them because there are no source code anymore. And you want to be able to use them. I don't know if it's a reason to stay on IBI. Yeah. So, I mean, I don't

have a company or even work for a company really, so I guess I don't. Yeah. My opinions, you can take them with a grain of salt but i'm thinking the playstation argument i get that that's the first one that i've heard in a while that i think actually like makes sense to me because you have a device that's shipped with libraries on it for example uh but the we're using a library from a bankrupt company that just sounds like a business liability because you have no way to fix that.

Someone was arguing that some government system is using this library and... Well, then... No further comment about this. Some government processes are very slow, so that's easy to believe. Okay. So it depends.

If you are a company using C++ internally for backends that's easy but if you are shipping something it can be problematic right for example for example a windows platform it's easier because uh you can ship multiple version of a standard library right it's no problem so there is so many voices and we couldn't find any consensus to do anything significant, which is probably good. I don't know. So it's mostly that status quo is still here. That should be a fun exercise for the listener right now to go in.

If you use Windows, go into add remove programs and see how many different versions of the Visual C++ runtime you currently have installed. I bet it's at least six. Yeah yeah especially if you play any pc games yes right so yeah it says here uh that they did you know that there's no uh pursuit to make a clean abi break at this time but they did affirm that authors should still be encouraged to bring individual papers for consideration, even if they would break the ABI. So, I know you're saying status quo, but I know one of the things Titus was saying is that if someone brings forward a paper, but someone realizes it's an ABI break, that usually means that paper is just dead on arrival.

Is the committee maybe changing their stance on that? Yeah, there's a slight change in it. In the past, if you bring any paper with a slight ABI break, we just said no. We cannot do that. But now we will at least discuss that. Progress.

If we find consensus in the committee, we can break a small part of ABI. Same thing happened with std list and std string in C++ 11. Okay, right. But I don't know about you, but it still haunts me in our production, so I don't know. No, last time it came up for me at all was a while ago,

at least five or six years ago. But I do know other people who've been hit by it very recently also i feel like there's no chance we're going to get through every part of this trip report time wise so if you don't mind i'll take a quick skip down because you just said that they are willing to discuss abi breakage now there's some discussion about RegEx for C++23. Yeah, I was in the room. Okay. Good. So it sounds like fixing RegEx would be an ABI break,

and so they don't want to do that. Yeah, we discussed one paper to fix RegEx to support Unicode from one guy from Japan, and we found that it's hard to do in current implementation. It's almost impossible. So we discussed that we will write a paper about deprecation of Stata Regex.

Right. And we will present it next meeting, and if there will be consensus, we will deprecate Stata Regex. Given we cannot break ABI. If we can break ABI of std regex, we can fix it. Are you also going to deprecate bind while you're at it?

No, sorry, it's completely off topic. This is going from SG16 Unicode group, so we cannot do bind. So if you are involved in that paper to either fix or deprecate stdragx uh only deprecate paper only is it is it fair to say you might be slightly biased in this uh discussion yeah i propose i think during discussion to deprecate it okay so. But most people in the room

agreed. That's the right direction because performance-wise, it's the slowest implementation. And if you want some Unicode support or anything, it's simply broken. Is the idea to deprecate

and replace it with a different library, maybe something that looks somewhat like CTE RE? If someone brings paper, yes. I would prefer to write the paper, but there are time constraints, so I don't know.

But I will try to bring it. I don't know if for next meeting, but for the next one probably yes. But it's still just CTRE, and I don't know how much I will be support from ECMAScript. They will probably back-shed the proposal and ask for more features, and then performance will go south. Is that the right term?

You've got to go south. That works, yeah. Well, sorry for that diversion we can go back up in the paper if you would That's okay Yeah I want to interrupt the discussion for just a moment to bring you a word from our sponsor This episode of CppCast is sponsored by

the PVS Studio Company The company produces the same name PVS Studio Static Code Analyzer that has proved to be great at the search for errors and especially typos. The tool supports the analysis of C, C++, C Sharp, and Java code. The article 012 Freddy's Coming for You, which has been recently posted, clearly demonstrates the analyzer's outstanding abilities of searching typos. The article shows how easy it is to make a mistake even in simple code and that no one is immune from making it. You can find a link to the article in the podcast description.

There's also a link to the PVA Studio download page. When requesting a license, write the hashtag CPPCast and you'll receive a trial license for a full month instead of one week. So yeah, after ABI discussion, the next thing on here is the Evolution Working Group Incubator, or Oogie. And one of the things that... I wasn't there, so... Oh, you were not there. Okay. No. One of the things I did want to comment on was another list, or I guess we had recently, was Vittorio Romeo.

And it looks like the epoch feature that he was proposing did not get any consensus to proceed. They found some problems, potentially with concepts that would lead to ODR violations. Oh, with templates. With templates, because templates in some implementations are implemented as a stream of tokens.

Okay. And if you have a template from a different epoch,ch it can have different meaning based on epoch and you cannot easily fix that. At least that I heard, I wasn't there in the room and I found funny because epoch from Rust

are inspired by our switch std version of standard. So epoch in Rust was inspired by our switch to specify a version in compiler and we are bringing it back to C++. That tends to be how things go.

I wonder if that's the end of Epochs or if Vittoria will find some alternative proposal, I don't know. Not sure. I don't know. Anything else you wanted to highlight with the Oogie papers? I was under.

Okay. How about you, Jason? You know, we want to talk about anything. The partially mutable Lambda captures I get, but it's weird because it kind of breaks how Lambdas well doesn't break how Lambdas are implemented, but it's weird. So teaching the implementation of Lambdas for people who care would be slightly weirder than it is today. This is allowing you to mark parameters mutable instead of marking the entire lambda mutable to say that it can, excuse me, captures mutable instead of the entire lambda saying that captures can be mutated. Yes. So in this case, that's interesting. Yeah. So if I understand right,

and I was actually just thinking about it this morning before we got started here, if you mark the capture mutable, then that would actually add a mutable keyword to the object and the implementation of the lambda. Whereas today, when you mark the lambda mutable, it removes const from the call operator in the implementation. So they kind of do the same thing, but by different mechanisms. Yeah. And then also C++ should support just-in-time

compilation? Yeah, I was in a room, and as you said, we discussed this paper. Okay. Okay. And we asked the author to bring the proposal again and asked to discuss with the author to bring the proposal again and ask to discuss with the authors of Reflection if there is a possibility to have the same API for both,

because it's actually a similar feature. Maybe they will return with something, or they will return with something that's different. But we asked to do this research, something or they will return with something it's different but we ask to do this research because until now it was just two separate proposals and they didn't look on their work so

we asked them nicely to talk to each other. What other working groups did you spend some time in, Hanna? I was a few times in EWG, but I don't remember much. I was in my room. I was stressed for a week, and I got sick after that. I'm sorry to hear that.

That's okay. We can just do a high level on these things in EWG. Many of them talk about things we've talked about on this podcast. Deducing this got some movement, it looks like. I was in the room. Yeah. So deducing this is the ability to template on this. So today, where you might have to write a const and a non-const overload

and an R-value overload and a rvalue reference and an lvalue reference overloads for your member functions or whatever you can template on this instead and avoid writing all the different overloads so that got some movement and std embed it looks like might be moving forward

yes std embed got nice positive feedback and it looks like on a good path. One I'm looking forward to. It seems like every other week I'm like, yep, could use to do it in bed here. Yeah. It's really nice how the committee shifts from,

no, we cannot do that, to, yeah, we actually like it. And actually most of the work is because John Heath did a lot of benchmarks and analysis, and he actually did some implementation in GCC, and I think he's

working on Clang implementation. Right. And it looks promising. That definitely seems to help if you can bring in implementation with your paper. There are some interesting issues with Unicode, by the way. If you ask for a file with Unicode name, during compilation there are multiple translation phases. And your encoding on source files can be different than encoding of execution

encoding. And compiler can convert the source file encoding into execution encoding after preprocessing phase. But stat embed is happening after the preprocessing and you can ask for some

file name which cannot be expressed in execution encoding. So we ask in Unicode group to not support const char star names, but only U8 and

U16 string-based names. That's interesting. Because they are explicitly marked that they must be unicode. Right. Huh. Because it can happen that source encoding can be unicode but execution can be some

abdic or something really odd. Sorry IBM. And then if you want to convert it back to UTF there can be it's not isomorphic so it's lossless

so we ask only for Unicode support nothing else it's funny that you bring up old IBM encodings as potential problems because I've been aware of them since I started studying computer science in 1996 and through my whole

career but i have never once actually had to interact with one of those old encodings i know people who do i have friends who work in the banking industry and we're regularly moving data between old mainframes and stuff and dude but i have not personally. Yeah. At least a few people in the committee need to work with IBM, so we need to support AppDict. But it's not just about AppDict. It can be on Windows. Your compiler can have execution encoding

different than Unicode. Right. I find this next random thing that's actually right before Embed that there's more discussion about fixed layout floating point types, float 16, float 32, float 64. And I don't know why, but I just find a short float, a float 16 to be just fascinating. Like I just want to work with one. Like when do you need that low of precision and still want floating point?

Actually, I'm not using floats at all in my work, so I'm not sure about machine learning or GPUs when you don't need big precision. Right. I still want to play with it, though. I want to see it. Actually, I think the proposal came from someone from NVIDIA. So I'm not sure, but they want to express floats from their GPU. Yeah, that sounds right.

That sounds familiar. Yeah. One of the other things that went through EWG is pattern matching, and it sounds like that's making some good progress. Pattern matching is a long-term project. And it's from, I forget his name. Michael Park?

Yeah, Michael Park. And it's a much better switch statement. You can have switch over content of tuples or vectors or arrays. And Michael Park in CPP Now last year, he presented a pattern matching proposal and he showcased customization points so you can provide your own mechanism to work with pattern matching.

And he showcased a really nice example with CTRE. So you can have pattern matching over a regular expression from text. If a pattern looks like a US style date extracted, if it's a style date extracted

month, year, day, and so on. Okay. It looks really nice. Core working group, then? I wasn't there at all and uh they are usually doing only wording so this on this meeting they spent uh mostly about checking if everything is as it should be like perfect and correct so they're like no significant changes from core working group because they are doing actually the standard text work. So they are sitting in the room,

and there is like a hive mind. There is no projector, and it's silent there. And they are just looking at the proposal, and now and then someone says, missing comma in paragraph 3 second sentence. Others just note and continue. Wow. That's like

an episode of Doctor Who or something, I'm pretty sure. Don't get me wrong, they are like the most brilliant minds of the committee. Sure, yeah. If they can communicate via telepathy, then they must. They're making sure C++,

there is no like, no like contradictions and there is no like corner cases, unspecified and so on and so on. Right. Well, there is one thing in here though. I mean, well, there's a bunch of stuff about modules and inline stuff that we already hinted at um a syntax gotcha for requires

expressions i'm happy about that but i'm not even going to click on it because i don't want to know the details uh but then i it is going to be an error to treat initialization of a bool from a pointer. That will be an error. That will be a narrowing. Sorry. So, yeah. Initialization of bool from a pointer. This is one of these things where people will post tweets and say, like, Shafiq, like, does this code compile? What does it mean?

And it often comes down to this kind of thing. I saw an example for this paper, and it was calling some function with const char star. Sorry, const char star. And example was like function and string yes, no, true, false, or something. And because they are all non-zero pointers, they were always converted into true, silently. Oh, into, yeah, it blew up, sorry.

So it will never happen. And I think some competitors are already warning on this. So it's just making standard practice, and no one should use this intentionally. So they're making an error. And so it says retroactively which i find interesting because the only other retroactive change i'm aware of is uh auto with initializer list deducing initializer list in an auto context and it looks like so this change will go back to

c++ 11 so if you compile with any version of C++ after C++11, then this will now become explicitly an error. If I'm reading that right. You can do that with defect report. That's interesting. There's other things I would like to defect report. Yes, the checks.

Maybe the 17 different overloads to standard pair since we just mentioned a moment ago uh maybe we can talk a little bit more about uh the sg7 group that you are the chair of uh according to this you spent some time talking about circle which we also discussed recently on the show yeah we had a long discussion about uh circle metaprogramming Model and there was a paper arguing against it and there was a paper arguing for it

and the discussion mostly went into the direction if you want to support running any arbitrary code during compilation in your build system. Many people are scared of it, including me. Because if you can run any arbitrary code from external libraries

or even just from C++, it's a potential security issue. Okay. For example, if you can run any library, it's really easy to load something and do anything in your build system. But even if you can run only a standard library, we have an additional pool if you want to allow only standard library code. For example, in my mind, there is an example. For example, you have a build system which is cut from the Internet. So there shouldn't be any issue like infecting something.

But same code can check during compilation if it can connect to internet. And if not, it won't do anything. But if it's on developer machine, then same code can contact internet and change itself, modify file in your source code and infect itself and go into, uh, into the, uh, and push itself into your, uh,

gate. So completely silently, you can have a malware in your code and it can be problem for some, uh, for some, uh, companies which distributes, uh,

applications. Yeah. That's a scary idea. And it's really hard to, uh, like block everything because it's just another, uh's a scary idea. And it's really hard to block everything because it's just another vector to attack and it's just running

untrusted code in an environment no one is used to run anything. If you look at current context per, it's limited and it's actually a functional language and it cannot change anything. It can only compute something. Right.

No, go ahead, sorry. If we address std embed or something, we can read files, but we cannot change them. So it's still reproducible and kind of secure. And the vote, there was a consensus we don't want to run any arbitrary code. Even we don't want any arbitrary code using only standard

library because we are going to get networking. We already have file system. So, yeah. CodeXper has many caveats, but we are making it better. If you want to start spending time on Circle

or Circle-style programming, we will introduce new keywords or I don't know which direction we will take. And we will introduce another sub-language somehow limited or we cannot just delete

context-performed standard because it's already there. People are using it. So it's a lot of work, and the discussion was quite heated. We actually ran out of time, and the poll results are... We are afraid of security, and we didn't decide to take the whole proposal, like take everything from Circle into C++, but we can take pieces of it.

If we like something, there can be proposals in the future for a specific thing. Actually, the competing proposals wasn't actually proposals. It was mostly discussion of what we can do and what we cannot. And current status

with Concepts Pro and current status with Circle implementation. And it was like, show everyone we can do this and we can do that. We should discuss the direction we want to go. That's really interesting. Well, there are other languages out there today that are compile time besides Circle that allow you to do any arbitrary thing at compile time.

And the people who are proponents for that say, yeah, you should be allowed to do any arbitrary thing at compile time and the people who are proponents for that say yeah you should be allowed to do it why not but i'm it is a bit sobering to consider what uh what you're suggesting that just simply compiling code is and now becomes a threat vector that would yeah yeah and if you uh not one c++ developer is used to think about security in this way. No. We have a hard enough time thinking about security of the code we're writing. That's true. And so if we are going to this direction, maybe in future,

we need to learn how to think differently. For example, people are used to PHP or any interpreted language. They are used to this thinking. Right. You're running what you're writing immediately, but we are not. In the discussion, there were some arguments that Circle currently is not cross-compiling. So if you are cross-compiling, for example, for GPU with different behavior or floats or anything, you need to emulate somehow.

And you need to emulate all combination of switches. For example, if you have soft FPU or hardware FPU enabled because they're behaving differently. And you need to have libraries available for all combinations if you want to have proper and reproducible build. Yeah. I mean, cross-compilation is hard enough already in many contexts. That's something you have to deal with too, huh, Rob?

Or you used to. I still do. Both Android and Windows, yeah. Okay, yeah. Okay. Well, I think we're starting to run a little bit low on time, Hannah. Were there any other papers or work you did in some other study groups

that you wanted to highlight before we let you go? I think that's all I remember. Well, yeah, it sounds like you had a very busy week, and the consensus is we're all happy that C++20 is done, right? Yeah. Before we will end, I would like to thank all people which were available to me, which helped me with organization of the meeting. Namely, Ratka Saberova from Avast,

which she did almost everything from an organizational perspective. And all my friends, which was available to me to let my stress out and it was really helpful so yeah good well it's great having you on the show again today hannah thank you thanks for coming on 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 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