CppCast - Jacksonville Trip Report

Episode Date: March 22, 2018

Rob and Jason are joined by Patrice Roy to discuss the Jacksonville C++ Committee meeting and the state of features that may make it into C++20, new Study Groups and much more. Patrice Roy has been playing with C++, either professionally, for pleasure or (most of the time) both for over 20 years. After a few years doing R&D and working on military flight simulators, he moved on to academics and has been teaching computer science since 1998. Since 2005, he’s been involved more specifically in helping graduate students and professionals from the fields of real-time systems and game programming develop the skills they need to face today’s challenges. The rapid evolution of C++ in recent years has made his job even more enjoyable. He’s been a participating member in the ISO C++ Standards Committee since late 2014 and has been involved with the ISO Programming Language Vulnerabilities since late 2015. He has five kids, and his wife ensures their house is home to a continuously changing number of cats, dogs and other animals. News C++Now 2018 schedule online Text Formatting at the ISO C++ Standards meeting in Jacksonville 2018 Jacksonville ISO C++ Committee Reddit Trip Report Patrice Roy @PatriceRoy1 Patrice Roy's Blog Links ISO C++ Jacksonville Agenda Sponsors Backtrace JetBrains Hosts @robwirving @lefticus

Episode 142 of CppCast with guest Patrice Roy, recorded March 21st, 2018. This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount

for an individual license on the C++ tool of your choice. CLion, ReSharper, C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at jetbrains.com. In this episode, we talk about the C++ Now schedule. Then we talk to Patrice Roy, who just got back from the Jacksonville C++ committee meeting.

Patrice talks to us about the state of upcoming C++ features, new study groups, and more. Welcome to episode 142 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing tonight? I'm doing all right, Rob. How are you doing? I'm doing just fine. I don't really have too much to share. I just kind of want to jump into this interview, right? Well, yeah, I'm sure our guest has lots of interesting things to tell us today. Okay. Rumors, rumors. Oh, look at that. The guest's jumping in too early. Real quick, though, let's read a piece of feedback.

This week we got an email from Rodrigo. He's a Mexican developer living in Portugal, and he wrote in that he enjoys CppCast and wants to thank us for doing it. He says he wished he lived in a city with a C++ user group, but you never get what you want. And he said as a regular Cinder user, he wanted to suggest Andrew Bell as a guest for the show we have talked about Cinder a while ago that was a really early episode of Vittorio Romeo

but it would be great to have Andrew Bell I'm assuming he's the creator if not a major contributor of the library I've not actually used Cinder, have you? No, I have not, but it seems like a great library. And I am curious, since we have this conversation relatively often with our European guests, that in a mixed environment, they tend to speak English at their offices, right? If it's people from various parts of Europe.

And I was just curious, Mexican would be a presumably native Spanish speaker, and Portuguese, yeah, Portuguese is related to Spanish, but it's certainly not the same language. I'm very curious if they speak Portuguese in their office, or if they speak English or not. Maybe he can write in and let us know. Yeah, let us know, Rodrigo. And the one thing I'll say is, you know, if you don't have a C++ user group right now in your area, look for other C++ developers and get one started. You know, that's how user groups get formed. Right, Jason?

Yeah, that's, yes. You just put one up and see who shows up. Pretty much. Meetup.com, really easy way to get it all running. 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 cpcast.com. And don't forget to leave us a review on iTunes. Joining us today, again, is Patrice Roy.

Patrice has been playing with C++ either professionally for pleasure or most of the time, both, for over 20 years. After a few years doing R&D work and working on military flight simulators, he moved on to academics and has been teaching computer science since 1998. Since 2005, he's been involved more specifically in helping graduate students and professionals from the fields of real-time systems and game programming develop the skills they need to face today's challenges. The rapid evolution of C++ in recent years has made his job even more enjoyable. He's been a participating member in the ISO Superfloss Starens Committee since late 2014

and has been involved with the ISO Programming Language Vulnerability since late 2015. He has five kids and his wife ensures their house is home to a continuously changing number of cats, dogs, and other animals. Patrice, welcome back to the show. Well, glad to be there. And since I'm home tonight, you might be hearing some of these beasties at some point. So what is the menagerie up to at this point? It's a very low number. There's only nine cats in the house right now. It's the lowest we've had in years.

I can assure you that if my wife were to walk into that house, she would not be able to see because of her allergies. Yeah, that happens. We've got up to 25 for a while, but it's 9 right now. It's a lower number. There's three dogs. There's one that's not ours. Three birds. And yeah, life. That's great. Oh, yes. Life. You can ensure that the house is always full of life at that point, I guess. There are places calmer than my house. Okay, well, Patrice, we've got a couple news articles to discuss.

Feel free to comment on any of these, and then we'll have plenty of questions about everything that happened down in Jacksonville this year. Okay? Of course. Last week. Okay. First one, C++NAT 2018.

Schedule's up, right, Jason? The schedule is up, yes. Lots of good stuff on here, it looks like. I realize I didn't even check to see what talk you have that made it in here. Initializer lists are broken. Let's fix them. Yes. Okay.

That is my talk. We can ask Patrice's opinion do you agree initialize or let's start broken not completely not completely but not completely there are things to fix it's there's so many good things about it it's sad that the bad things show up so much but i when i saw your talks title i was enjoying myself a lot. Many people think like you do. The fixes are very difficult to find. It's a tricky thing to fix. Yeah, we will, I don't know, we'll see what I come up with in time for the conference. Well, there's that and there's the aggregate initializers that follow the same syntax. And there's the default initialization with the pair of braces that I think is awesome.

There's many good things about it, but no, the vector int situation is very unpleasant. Yes, and I am specifically referring to the actual initializer list object itself, the thing that is creating for you behind the scenes, yes. I'd like to be in the room listening to you hacking through that thing. itself, the thing that is creating for you behind the scenes. Yes. I'd like to be in the room listening to you hacking through that thing. I'm very, very curious, but I'll be watching it on the internet at some point. Right. You will not be making it a C++ now again, I assume. I would love that. It's one of the conferences that sounds so, so cool. I was looking at the listings today and damn, it looks good, but it doesn't fit well with my teaching schedule.

Yes, and for those who have not yet signed up for it, go buy a ticket now, talk to your employer, do what you need to do. It is definitely the conference to go to if you're interested in, well, people who are tearing apart the language, I guess. Absolutely. Yeah, it's the conference that does that. Yes. Is there any other talk you wanted to highlight jason oh i don't know uh i had a few places myself where i couldn't decide which talk to go to but

there's one about quantum data structures for classical computers that sounds interesting yeah that's peter yeah yeah charles bay i think is relocatable is something that we've talked That's Peter. Charles Bay, I think. Is relocatable is something that we've talked about on the internet a few times. That's interesting. Archer is going to be talking about that. Archer O'Dwyer, please allow me to say, he's got a book out. I got a copy. I didn't finish it yet. It sounds really, really cool.

So if you get a chance to look at Archer O'Dwyer's STL book, Mastering the STL, it really seems interesting. I think we mentioned that a few episodes ago. Yeah, two weeks ago, I think, or so. Yeah, I think we did. Okay. But there's a number of cool talks. Something about efficiency by Alan Talbot, I could see. Something about data parallelism by Jeff Hammond.

Your talk seems interesting. Bob Stegall's Fancy Pointers. Things by Odin Holmes. It's an awesome conference. Yeah. Yeah, I misspoke when I said that wasinters, things by Odin Holmes. It's an awesome conference. Yeah. Yeah, I misspoke when I said that was Peter, and you're totally right, yes. Peter's talk, at least one coming up here,

A View to a View, looks like it could be interesting. Definitely. There's so many people that have been guests on the show that will be speaking at this conference. Well, your show's very good. Yeah. Oh, thank you.

There's a couple names I didn't recognize, though, who we might need to try to get on the show. I saw there were two talks by Jason Rice. One's on Docker-based C++ dependency and build management. That sounds like it would be interesting. It's a hot topic. I believe Jason is a regular at this conference, if it's who I'm thinking of.

Okay. Well, next article we have is text formatting at the ISO C++ standards meeting in Jacksonville. And this is an article from the author of the proposal to get formatting into C++, and it's based on the format library. And it sounds like it's going well, and it's on track to be in standardization, I believe, right? It's got a good reception from what I understand. I wasn't in a room when they discussed that.

It wasn't accepted. They talked about it. The votes were mostly four. There's some fixes to do. But it's cool. People tend not to like the Iostream-style formatting. They find it's a bit too long. I don't mind, personally.

I meant about the implementation, but not the syntax. It doesn't bother me that much. But I think people will like what Victor is doing. It looks like what people are used to. It does lots of compile time stuff. There's some interesting macros in there that are very, very funny. Yeah, I think it's very similar to Python and C Sharp

and I'm sure other languages style string formatting. And since the compile time strings are really coming our way, it's probably going to be a good match for what he's doing. Yeah, I thought it was interesting that he said one of the things that he had to address was compile time string format processing from the last one to the current one.

But it's coming, it's coming. So I'm curious though, it has, he, the author gave us the list of how many votes were strongly for, for, neutral, against, and strongly against. And you said it was not accepted. And I'm curious, what does it take for it to be accepted? What does this vote have to look like? It depends on what the question was.

Was the question, do we encourage the author to pursue? Was the question being asked, do we like the direction this thing is going? I wasn't there, but my guess is he presented what he's done. He asked a number of design questions, probably. He got answers. He got guidance. And

my feeling is that since it was probably an encouragement vote, he's going to go back home, fix a few things, and then come back with something that's stronger. And if both LEWG and he feel good about it, it's going to move on to LEWG and then maybe get into the standard for 20 or 23. Okay. Okay, and then this next one we have,

and this might just kind of flow into the rest of the show. We have an ISO,++ trip report on Reddit, and it was Bryce Lallback who put this together and went into just a good overview of what was discussed at the meeting and also what the targets are for what might make it into C++20 or C++23. And maybe it's worth starting there because I'm really glad that

this was put out there and I'm sure that this is the committee kind of wanting to be honest with the community about what is going to make it and don't get people too excited because that's kind of what happened with C++17. We were expecting a lot more and some people were let down.

And this list basically is saying, conservatively, we think there's going to be at least these two major features. And optimistically, there could be like six more features. So it'll probably be somewhere in between. Right? That's

when we're putting it. Some big features are really coming in we have concepts you know we have concepts so concepts was officially approved it was approved at the toronto meeting the uh what's still floating is the terse syntax issue because there are disagreements since there are cases where something could be a type or a non-type. Some people think it's not a problem. Some people think it is a problem. So that's why this thing has the favor of a short majority of people. So that's not consensus. So concepts are in, and there's still discussions going on about parts of the syntax. Modules have made progress in a surprisingly and interesting manner at the Jacksonville meeting because the two, let's put it that way, the two competing approaches found a lot of common ground

and have told us that they would be co-writing something for the next meeting. I got out of that meeting with hope for the module's proposal. I think we could actually get something for C++20. It sounds solid now. So that's pretty major. Since we're talking about modules,

I've seen lots of comments going back and forth where effectively a lot of developers don't want modules if they shoehorn in macro support, basically. Yeah. You know, we're going to get whatever we agree on because it's a political issue. I don't think we're going to be able to escape the macros entirely because there's too much code depending on it. It's not a fresh start where we drop everything and start over again.

It's not going to be like that. I don't think so, at least. But we'll see. You know, the two, as I said, the two competing approaches from two major contributors seem to be going in the direction of something that fuses the common parts. So at least to get something to C++20, I think there's serious hope that there will be modules in some form. That's not to say it won't evolve after that, but we're going to have something, I think.

It sounds good. And in this trip report, it mentions that an entire day was spent discussing modules in the Library Evolution Working Group. And that was not the biggest part of the meeting. Wow. But yeah, I wasn't there at that part. Some people are getting saturated with modules. It's a very big thing. It's been going on for a long while.

Some people are not as interested as they used to be, but we're going to get them, and they're going to be useful. They won't be miraculous, but they're going to be useful. The biggest thing was in that it was integers. Integers? Integers. We had this proposal. Yeah, yeah, integers, signed integers.

Signed integers, yeah. And to complement, that was a very big issue during the week. Yeah. I didn't actually realize that it was discussed. I don't recall reading it in here. It took a day and a half. It was the biggest SG6 meeting I've ever seen. SG6 is numerics.

I wanted to go there because the undefined behavior people were going there too. I work with them most of the time, but the place was jam-packed. There was this proposal to make all signed integers two's complement in C++ and essentially remove undefined behavior on overflow.

Okay, so are we aware of any currently existing hardware that does not use two's complement? Well, that was the beauty of it. The guys had done their research and they checked a number of hardware and vendors, and the only pieces of hardware we could find that do not have Tooth Complement do not have a C++

compiler. So it was a surprisingly successful proposal. It didn't pass because it's a big thing, but there was a day and a half of discussion there, and it was surprisingly serene. Okay, now, I'm struggling to think of where hardware even needs to support

two's complement. Like, arithmetic shift right needs to know if it needs to extend to the sign bit. But from a CPU perspective, for the most part, the beauty of two's complement is that it just works with addition and subtraction. I guess you need to complement, you need to... Negating a value needs to know that it's two's complement in the hardware. Yeah.

The undefined behaviorness or not of overflow is an issue too. Do you detect an error? Do you report it? What do you do with that thing? It's a sensitive issue. But we kind of had an explosion. It was very well managed by all participants. And we had progress. And I think we're going to have another paper at the next meeting.

And the language is going to change in a fundamental way with that. So plausibly, two's complement will be the defined way that signed integers are implemented. I couldn't swear anything, but I couldn't have believed that at first. And after that meeting, yeah, I think it's a possibility. And so the main author of that paper, is that JF? Yeah, JF likes controversy. he's very good with that okay but he's amazingly efficient i mean he managed this like a like a yeah like a champion

wow that's jf bastion we've had him on the show before just for the sake of our uh yeah you have a long time ago talking about web assembly when when that was still being just an idea, really. Yeah. Yeah, well, he's one of the engineers behind that thing, yeah. Wow. Well, I mean, that's arguably the main category of undefined behavior that affects real programmers. Yeah, I'm not sure everyone understands what they're doing when they're doing signed overflow. They expect their machine to be doing the right thing or their compiler to be doing the right thing, but they're in UB land all the time.

They're working on false beliefs. So at least we could get something that actually makes sense and results in portable behavior. We'll see. But that was one big thing. There were many things during that week. It was a busy week. Well, we're still talking about core language things, or major features, I guess.

Are we still talking about major features? As you wish. Yeah, I mean, is there any other news with major features being worked on? I mean, we just briefly spoke about concepts and modules. Yeah, SQL routines are going forward also. We've made progress. There's still things to work on,

but we had an evening on coroutines or an afternoon on coroutines. And even those who don't think it's ready want it. So I think there's hope for coroutines also, which is a pretty cool thing, yeah. I'm really curious about this executors thing, because it was only recently brought to my attention. And we've been talking about the networking

TS for, I don't know, years on the show, right, Rob? I mean, networking's come up many times, but what are these executors, and why does networking rely on them, and why don't we have executors if networking requires it? So I went and did some research to make sure I didn't say anything that was too wrong.

I don't sit at SG1 that often, so I follow the things from an outsider's perspective still. So an executor, what it does is model the execution of agents. It tells you if they have completed, if they have completed well or not, how they are being distributed among machines or among cores or among threads. It manages the execution of things. And there's many kinds. There's the one-way executor, the two-way that returns some results, the then, to do future.then and chain things

into continuations. You can bolt them together, so you can do fire and forget for a number of agents at once, or send a number of them and pack the executions into a big array and send it back. So they model the way that the computations are being distributed on your hardware. They're an essential part of what concurrency will be in C++ starting now. And they're a big thing. And the networking that exists based on Boost.io,

ACO, is cool, but it's been re-based on executors for C++ 20 and up because future.den, fibers, everything kind of relies on executors. It's the abstraction that we're putting underneath it all. So lots of things depend on executors, and we really, really need them soon. Okay, I'm going to put on my cynic hat for just a moment, and hopefully I don't go too far down the cynicism route.

But occasionally, things can come across as being over engineered and being far more flexible than the actual like average programmer needs and now you're talking about the executors as modeling the way that concurrency happens on your hardware will the average programmer be able to understand this executor thing, or is it going to be like this black box that we just have to deal with? You probably won't see it from a programmer's perspective, although from what I can understand, there are a number of customization points in there

where you can tweak things to make them behave the way you want to, if you're an expert. There's prior art for that. There are executors in Java and other languages, so it's something that is quite well understood. There's a sound basis for that. It gives you guarantees on blocking progress and other things. So it's a way to model concurrency, parallelism, forward progress when you're computing. It's a solid thing. To be honest, we need this and we've needed this for a while, but for all the new concurrency and parallel stuff,

to make it work properly, we kind of need that. Now, the thing is, will we get that for C++ 20 or 23? Right. The SG1 people have presented two options. One of them is we wait for 23 and we get a bunch of stuff at the same time, or we push the ones that are ready for 20 and we try to get networking running right away.

Those two options are on the table. I don't know where we're going to go. We're being asked to think about it. So we might get networking and basic executors for 20 and the rest in 23, or we could get everything in 23 all at once. I don't know right now what it's going to be. Okay. Interesting.

Yeah, it's a very interesting thing. If you look at the specs, there's... I wouldn't say over-engineered, but it's a way to think about the way things execute on your machine, so it makes you think. That's a good proposal. Alright.

I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Bactres jumps into action, capturing detailed dumps of application and environmental state. Bactres then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more.

This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary.

Check them out at backtrace.io slash cppcast. How about ranges? The conservative target is saying the core ranges are going to be in C++20 and the rest in C++23. What exactly do we mean by the rest of ranges? I had to look this up

because I wasn't in the room for that one. I was in core when that was being discussed. But I think it's a misnomer, to be honest. Now, don't quote me on that because I've been going through papers, my note-taking there, because I was it's a misnomer to be honest. Now, don't quote me on that, because I've been going through papers, my note-taking there, because I was a secretary at the meeting and everything. There has been no

core range proposal being accepted in the meeting, but the standard library concepts, P0898, have been pushed from LEWG to LWG and ranges do depend on that

so my guess is that's what people meant when they said that the core range was being accepted it's gone to LWG for wording now so that thing is the concepts on which the ranges are based on that is my understanding

of things but if I'm mistaken I'm sorry but I think that's what's going on the ranges are based on. Okay. That is my understanding of things, but if I'm mistaken, I'm sorry, but I don't really think that's what's going on. The ranges TS and the complexity requirements were discussed, but not forwarded. So that means LEWG has worked on it. They're probably good. They might get into C++ 20, but they would have to go from LEWG to LWG

during the next meeting, which is something that happens sometimes. If they're almost ready, they discuss it in Library Evolution, and then they push it to Library, and then it just gets the wording, and that's done. But it depends on the size of that thing, having looked at it.

That's what I think happened. The concepts for Library are there, which is probably what they call the core of the ranges, but the ranges aren't there yet. Okay, so perhaps to summarize, for ranges to get in, we needed concepts. Then we needed the concepts that ranges rely on. Then we need ranges themselves.

Yeah, we could make ranges work without the concepts, but it would be a major rewrite, and I don't think it's worth it. Yeah, no, that doesn't sound worth it. And I think this is probably a good point to take one step back and ask you what your role actually was at this meeting, as we keep badgering you with questions. That's okay. I'm there for that. So I replaced Jonathan Wakely as secretary for the second time. I'd done that in Toronto before because I don't mind. I type all the time.

I take notes. So I don't mind taking notes for the committee. It's more formal, of course. There are rules and everything, but I did that. And I spent most of my weekend core because we had a number of very interesting things to do there. So that's where I spent most of my time. I did all of the evening sessions to do there. So that's where I spent most of my time. I did all of the evening sessions, to my knowledge. I'm saying to my knowledge,

but there were days when we had more than one evening session going on at once. So you can't be everywhere at the same time. Of course, it doesn't work. Yeah, so that's what I did. Lots of core wording and lots of secretary work and lots of evening sessions. What goes on during the evening sessions exactly? Normally, it's things that everyone might want to attend. It's not necessarily as formal as the day work when we are in specific working groups with an agenda and votes and stuff.

The Monday evening session was on concepts and the Terse syntax. We had, if I remember properly, four proposals there, one by Vittorio Romeo and John Lacos, where they were using the auto keyword to introduce concepts. The thing with Terse syntax is that sometimes there's a confusion between type and non-type. People are working to clarify that. Those who find it annoying.

There was that. There was one by Thomas Kopp who wanted to use concepts as adjectives. You would have the concept name and the type name and then your variable. You would be qualifying your types with this. What would be the advantage?

I'm curious what the advantage to that would be. Well, you know, it's a type. When you're using that, you have no confusion, and you could have many concepts for the same type. So you could say it's a mergeable and sortable container or something. It's almost like a Java interface or something at that point. No, it was better than that. Right, I'm sure it was.

Thomas is a bright guy. There was one by Bjarne, if I remember, who really likes the original syntax. I agree with him that it's the most elegant one, but it's true that there are problems with it, confusion that might be bad or might not be, depending on your point of view. And there was one, the one that had

the biggest support, if I remember properly, was Herbs. Herbs introduces braces after concept names. You can introduce names with that and reuse them afterwards and make the syntax a bit lighter. It's a bit of an annoyance to have braces there. It's a bit of an annoyance to have braces there.

It's a bit strange, but it does have some technical and syntactic advantages. And his plan is to make them go away at some point. So when we're more comfortable, if you have a concept name and a pair of empty braces, because that's just what happened in your syntax, you can just go to the point at some point where the braces go away, and it looks like the original syntax

that Bjarne had brought up for years and years on end. So it's seen as a transition path. So we had that evening. That was a three hour and a half meeting in the evening. We ended up at almost 11 o'clock in the evening with that. So that was the first one.

There was one on Tuesday on new containers for the standard library where people were presenting either their work or some other people's work. I have to tell you that I looked like a clown on that evening. I presented one and I made a little mess out of it. Happily enough. But I felt terrible because I didn't do a good job. It happens.

We really must know what your terrible container was that you presented on that. It's not the container that's terrible. It's me who was terrible. Okay. I had a terrible job. I had a hard time believing. No, no.

I really made a mess. It happens. So for a number of reasons that are not to be discussed in this podcast. But happily enough, all of the other presenters were very good. So we had Casey Carter for a, if I remember properly, a fixed size vector. I may be confusing him with another one.

We had Nevin Lieber with a short, small vector, a small vector that starts very small and you can use the small object optimization on. The other one has a fixed capacity. I might be confusing one for the other. Sure. We had, I'm sure I'm going to forget one. one at a fixed capacity. I might be confusing one for the other. Sure. I'm sure I'm going to forget one.

We had Colony from Matt Bentley, whom you've had in the show before, I think twice. Was Matt there to present it himself? Did someone else present it for him? No, he lives in New Zealand. He doesn't come to meetings. But Nicolas Jusitis did an awesome job at presenting this

it was very very good and he got a very good reception from the crowd so that's amazing and I messed up but I still tried to present the slot map from Alan Deutsch which is a better proposal

than what I showed and there's one that's missing from what I just said I feel sorry Ringspan I see Ringspan of course by Guy Davidson who did a really good job. That one's really cool because it's been going through six revisions.

It's a good proposal, but sometimes people want a container. Sometimes they want an adapter. Sometimes they want something with specific behavior on pop and push. So it's been going through revision and revision and revision, mostly because people keep changing their minds. But now Guy was there, and he got a good reception, and it even went as far as the SG1 chair saying, we want the concurrent version of your thing, and we want it now.

So we were very happy about that. So apart from my mess, it was a very good evening. We had the Wednesday... I'm going to forget some. We had an evening session for the SG15 group tooling that was on Friday. Oh, right. So that's the brand new group, right?

First time that it's met? But we have a newer one than that. Well, yes, right. Let's start with the oldest new one and then go to the newest new one. Yeah, because we don't have enough work. So the SG14 had a very good reception. 15, right?

Yeah, 15. We need package management. We need tools to deploy. In fact, the problem is we have too much, too many papers going on in a readable UG to process these days. We can't take everything we're getting and get them through in a meeting.

They barely got to about half of what they got this time. Wow. So we need a different vehicle from the standard library to bring those cool things to people. So there's Boost, of course, that exists. And we're looking for a way to make downloading libraries and installing them easier. So people went to that meeting. for a way to make downloading libraries and installing them easier.

So people went to that meeting. People participated very strongly. People offered their time and their energy to provide tools and standardized tools and protocols. So we've given ourselves a 10-year horizon for that. We want in 10 years for people to be able to easily download and install library stuff without bothering. I'm curious if any of the existing tooling things out there, I mean, like Conan, for example, is out there doing things.

People are actively using it. Was it discussed? What relevance does something like that have in these discussions? Maybe. We didn't name anything. The goal is to get everyone working together. So it was a first meeting official like that. So yeah, I expect Conan to be contacted.

Lots of people in the room were actively participating in similar tools also. There's a number of tools we need. We have a long list. We won't get through everything. But I expect people like the Conan people to be contacted at some point and brought in if they want to participate. So it's not just package management

tools. No, no, no. It's a long list of tools. If you look at, if you have access to the wiki, you can look at the notes because I took them. They're very detailed. But there's a long list. We won't do everything that's in there, but we're going to get people working. There was an evening session on

concepts. We had an evening session on Unicode, which has led to the new group that's SG16, led by Tom Honorman, who's a very courageous man. And I'm missing one. There were so many. So yeah, we had evening sessions like that. There was one on static reflection.

Very important one. Static reflection is coming to... We could almost, I'd say... I'd risk myself saying we could have bits of that even in C++20 the way things are going. That would be nice. Okay. That would be a major feature.

Oh, yeah. Yeah, it's a big thing. It's going to be much bigger in C++23. But in 20, I can tell you that we are looking ahead to something very nice. The proposals we have are sound, they do good things, they lead to interesting code. We had a progress report from Herb on his middle class stuff that looks much nicer than it used to. It looked nice. It looks nicer today. We had work by David Senkel and a few others on ways to make concept programming nicer. Really, a very good

evening. And Bjarne presented a list of the things that they really would like to have right away. I'm very curious what Bjarne's list of things that he would like to have right away is. Well, he acted as a customer, so he wants easy serialization and a few other things like that. They're all very simple to do if you have the right tools. He doesn't want people to over-engineer.

He wants solutions right away to real-life problems. So, yeah, we might be getting a few of these. Yeah, it's really cool. So, yeah, I guess reflection would be a requirement for serialization almost certainly. Well, the serialization he looks for is something that is based on static reflection.

You can infer the names of your enums and then iterate through them and list them and display them and you can iterate through the members of your class and the member functions and there are things like that. We can already do them, really. It's a matter of your class and the member functions. There are things like that. We can already do them, really. It's a matter of getting them to the standard.

Yeah. I would love reflection for my own purposes, but being able to convert an enum to a string, like just that one little thing, if we could do that in some way that did not require macros or a bunch of duplication of values, would be really nice. Well, with Reflexper,

the new operator that we have, if it gets into C++ 20, you already have that. So Reflexper leads to, it gives you incomplete metatypes on which you can reason and from which you can deduce information. There's machinery behind that, but with what

we have on the table right now, you could do that. You don't need macros anymore to do that. That would be nice. Yeah, it's really, really cool. One thing that I could say is that with Jacksonville, you can see the frontier between runtime and compile time slowly disappearing and fading away.

Things are moving back and forth between the two. C++ is changing again. That is exactly how it should be. We should be able to make everything constexpr if we want to. I heard the rumor. But, okay, see,

you have these new constexpr new coming in, of course, but, and we have now constexpr iterators that we've gotten in to make things easier, but with constex context for new you can have context for vectors and strings you know oh so did context for new i didn't see that on any of

the reports did that make headway in this meeting no but i expect well it's not been voted i expect it to be in really there's a number of things depending on that but the new thing that came to core at the very end of the week, on Friday, is constexpr destructors. Well, that needs to happen. That's, in my opinion, way more obvious than constexpr knew, from my use of constexpr.

But the perspective, if I understood it properly, because it's pretty abstract, is that you're working at constexpr time on things like your constexpr vector, and you're playing with the memory that doesn't really live in your program because the program isn't there yet. So you're in the interpreter part of your compiler,

see doing things. But there are ways now that seem to appear of reifying objects that were constexpr into the runtime world as static objects. And the constexpr destructors would intervene at the end of your program to do cleanup on that static stuff that you've generated at compile time. So it's really a different way of thinking about code.

It's very strange and interesting and stimulating. Yeah, I see your face right now, but your listeners don't. But yeah, it's the kind of face I made too when I heard that. I'm thinking about it. Actually, it made me immediately think about it from the teacher's perspective. Because I really like to teach the fact that the object lifetime in C++ is something that we can strongly reason about. We know when things are created, when things are destroyed. Now, if we have something that began its life at compile time

and ends its life at the end of the program execution, that changes a little bit how we think about things. Yeah. But it's a very interesting proposal, thought-provoking. It's an evolving language. Static reflection does that too, mind you. And metaclasses too. You're pre-generating stuff before your program starts to run you're creating classes from code it's yeah it's it's a very different language we're going to it's a very

very interesting one yeah cool i had a lot of fun i don't know if it shows but i had a great week yes it sounds like you had a lot of fun yeah i want't know if it shows, but I had a great week. Yes, it sounds like you had a lot of fun, yeah. I want to speak about a few small features, if you don't mind. Sure. One of the first things that began my week was new unique address. So you might have heard about that. It's a way to tag your data members in a class to say that they do not require a specific address because they're empty, you know? Right.

That's cool for the classes where you would have liked to apply the empty base optimization, but that are marked final, for example. I didn't realize that final actually precluded the ability to use empty base optimization. Well, you cannot derive from the class, so it cannot be your base. Okay.

So you're stuck. But that thing is interesting because when you start thinking about it, if your different objects have no unique address, they can be anywhere in the class, you see. So you can put all of them at the beginning, regardless of where you put them in the list of your data members, you just shove them at the beginning because you don't really care where they are. So we have to wonder what is the impact of this on trivial layouts,

because you're moving the objects around. So, yeah, it's actually interesting. But that's very useful for embedded programmers, for people who care about the cache line, people who care about speed, of course. And we're actually going to get, in the context of a non-empty object, of course, empty data members.

That's a new thing and a new way of thinking also. You might have seen the likely and unlikely attributes also. Wait, wait, wait. I want to go back to no unique address real quick. Come back, please. Does that, I mean, one of these fundamental things of undefined behavior, this pointer aliasing thing, right, that everyone wants to complain about because they can't reinterpret cast bits however they want to in C++. No unique address means that we could have pointers

to different objects that are the same address, correct? Absolutely, absolutely, because they have no unique address. But now is this because we have to actually tag it with an attribute, now the compiler knows, okay, it's fine, I'm just not going to optimize around this thing, or does it even matter if it's empty? I don't know. What are the implications here? I have to think about it. Anyway, the compilers can support it or not. They're not forced to. It's just an attribute. So we'll see what they do.

It's Q of I. Our thought processes are going to adapt to that new reality. It's like if we ever get regular void, we're going to have to think about our code a bit. We need regular void. That wasn't mentioned on here at all. I'm guessing there was no movement about that. Because Matt could have raised when I was into the meeting.

That's why. We need to do a GoFundMe or something to make sure that he attends all the meetings and advances the cause of regular void. Yeah, that will be a game changer also if you get that. I want to

talk about Likely because people misunderstand what it's meant. It's an SG-14 thing by the name is Trita but I don't know if I pronounced it well but people seem to think that we're trying to second guess the compiler saying we know better than you what is good for you

like with the register keyword but that's not really the point the point of likely there is to tell the compiler you're right about the way you see things you're optimizing for the speedy branches and the frequent branches, and you're right, but I don't want you to do that. I want you to treat that else there

that you wouldn't have optimized normally as the optimal one, because I know that when I get there, that's when I want to go fast. So it's for people who don't want the normal code to be optimized. They want abnormal stuff because, for example, they want to exit the program very quickly when something goes wrong or something.

So it's a very niche thing, but it's not people trying to think that the optimized version of the compiler. I think that's not the way I understand it. So we're not just supposed to sprinkle it around wherever we think that something is more likely or less likely. No, you're going to get into trouble if you do that. And that's actually amusing, because if you look at the wording, there's a small number of words describing likely and unlikely,

and there's this huge note thing that you're going to get bitten if you abuse, because the compiler is better than you are. So the warning note is much bigger than the actual wording. This is like inline, which perpetually annoys me when I see it sprinkled throughout code. Yeah, except maybe for the new inline variables of C++17. Yeah, that's different. Inline functions.

You might have heard about the CD date. We're going to have an actual date type in the standard. I think we talked to Howard Hinton about that, right? Well, it's been accepted. This guy is a hero. You have any idea how complicated that thing is to write? It's awesome. So we really, really,

really appreciate what he's done for us. This guy is saving everyone. It's like Unicode. It's just too complicated, and Howard just went out there and just did it. We have span now. You might have seen that one. So like string view for arrays, that's really cool.

Is this the same as GSL span, just a simple one-dimensional thing? I think so. They're still working on the multi-dimensional one. It's tricky to write. Oh, yeah, yeah. Single-dimension span is easy, but the multiple-dimension one,

there's considerations to take care of. Some small bug fixes. You might have not noticed about that, but structured bindings only work with public members. Yes, right. That's annoying. You have your own private members. You cannot easily make a tuple or a pair of some of the members by using structured bindings within your own code because they're private.

Oh, that's interesting. But you have access to that. They're yours. You're a friend. You cannot make a structured binding out of the private and protected members of your friends. So it's funny because I ran into that bug two weeks ago. And a few days before I did,

Timur Dumler, I think, had the same bug and wrote a bug report, and we managed to get that one in as a defect for C++ 17. So as long as you have access to the members, you're allowed to destructure them, if you will. Which is really reasonable. Seriously, it's a really good thing. So we managed to get that

one right in, because everyone agreed that we should have done that from the start. It's a really good thing. Did you manage to fix the constexpr usage of structured bindings while you were at it? You need a paper for that. Oh, come on! Allow the constexpr keyword. That's all that... No, actually,

yeah, they are allowed... You need a paper for that. Okay. You need a paper for that. We only discuss things on papers. I assumed someone else would have, you know, because there's so much movement with constexpr and you know. No, people have to read. We barely have the time just to breathe at those meetings. Yeah. And we, as I told you, some of the committees don't go through half of the papers that they really get.

So we cannot do things that are not on papers. It's not manageable. Wow. The other thing is that if it's not on paper, we don't know what we're talking about. Yes, yes. You need something in writing that you can read, reason about, examples, something that's if it's not writing, if it's not written, it's not science.

You might have liked that, the very addict lambda captures. I was looking at that and I think I've only hacked that come up maybe once or twice that when i was and i just engineered around it in some other way yeah yeah there are tricks but the the fact that you can now you will now be able to do a global move of a pack within a Lambda at capture time. That's pretty cool, actually. Yes. Contracts. Have you heard about

contracts a bit? I've heard about them, and we talked to... Who did we talk to about them? Bjarne? Maybe. Juan de Garcia, maybe. John Lakers. There's a few others. We haven't had John on the show before. It was a while ago.

Interesting. Contracts made it to core this week. us. There's a few others. We haven't had John on the show before. It was a while ago. Contracts made it to Core this week. It's a very interesting feature that I think we can hope for in C++ 20. It looks good, but when you hit Core, sometimes you see things you hadn't seen before.

So if my understanding is correct, because this was the first time I was faced with that thing, contracts include a preconditioned part, expects, a post-conditioned part, ensures, and some assertions within the code. The preconditions and the post-conditions are part of the interface of the function. So the caller is actually aware of them.

Oh, wait. Does that mean now when I deduce function types, I have that many more things to add to my templates for deducing? No, not as far as I know. But it's something that can be checked by a compiler because it's part of the visible interface. And it only relies on public members if you're in a class. Because it's something that participates in the interface

that's visible to the caller. They can be turned on and off, that's fair, because sometimes you want them to be checked, and sometimes you don't care that much. So there's a number of good things about that. What struck us? One of the reasons we were discussing that thing in core is that you might want to be debugging your assertions or your preconditions by putting, let's say,

print statements in them. Now, if you do I-O or any other kind of side effect, you're kind of playing against the contract because contracts are not supposed to influence the flow of the code. So if you're doing new, for example, you might be breaking things, removing memory that you might need within the function, you might be interfering with the code. So the contracts themselves are not supposed to be side-effecting, but it's reasonable to let people do print statements if you want to trace their stuff. So that was part of the reason we were discussing that thing. And at some point, the fact that when you're calling a contract and you're breaking the preconditions, you're not meeting them, the people who are writing the proposal expect us, the compiler people, to report the point of call as being the place where the problem is.

So you're calling from that function a function, and you're not respecting its contract. Okay. Now, that's fine when you're calling the function directly. It's complicated if you're calling it through a function pointer or a virtual call, because they're not part of the function signature, really, these things. And someone realized that if we want to call C functions, say, and C++ functions, well, if you want to call C functions and C++ functions,

well, if you want to be able to report the point of call at all times, you have to introduce a trampoline in your code and allocate memory. It becomes a very big mess. So I'm not sure we'll be able to do that part of contracts for C++20. It seems much trickier than people expected. Happily enough, though, for us, there's another proposal on the table to report actual stack traces when requested.

So that may be something that is parallel to contracts, but that might make the code able to report stack traces nonetheless without introducing that overhead on each indirect function call. So there might be a solution for that that is outside of the contract's realm. Okay, so when you break a contract, what is the actual mechanism for what happens? Is this like an exception, or is it what?

I'm not sure. I don't know the proposal deeply enough for that. It's something I would have to look for. You can imagine maybe perhaps where my question is going is, what happens if you break a contract in a constexpr context? Again, I don't know the proposal enough to answer that, sadly. But these questions, what happens when you throw an exception from within an insurer clause or a required,

or not a requires, but an expects clause? These questions have slowed down the progress of contracts quite a bit because that's where the danger is. What happens when you're doing these weird things within them? Then you have to have a syntax like constructor try blocks, which almost no one knows even exists. Well, right now, you do, I do, a few others do. Right now, the thing is you cannot have side effects.

That's already something. So they're not supposed to break at any time because they're mathematical constructs. They're stateless, really, if you do them well. So it shouldn't be a problem, but we'll see. Interesting. Yeah, yeah. But again, to know more, you should ask the authors.

What I found interesting was this development that to really support contracts the way they were being brought to us, there would have been a hidden cost that we luckily caught at core. So now we'll see where we're going with that. That doesn't mean contracts are not good. Far from it. They're very interesting. But that part of it needs work a bit.

Yeah, if you had not caught it at core, then we would see tweets like six months from now from compiler developers about how this thing is unimplementable and it's going to have to go back. Yeah, well, it's implementable, but not at a reasonable cost. Right. But I think enough core is the, apart from people like me who are just there

because they find it interesting, they're the compiler writers, most of them. So they tend to see those things. Oh, that's good. Right. Yeah. So that's pretty much the big things that I could see. It was a very interesting meeting. I have one question that you did not mention.

And I am even looking at the paper, I'm at a loss. What is the version header for? Oh, that's interesting. Okay. So there's the ISO. I think ISO 646 header that already exists that tells you things about

your compiler and your machine or whatever, the tools you're using. And nobody really uses that. It's a bit of a mess. I'm not even familiar with it, really. Yeah, well, people keep talking about it, but nobody uses it ever. But in theory, it would tell you what your installation is like.

So, version, if I remember properly, because it was brought up, is something you could include to know. I'm going to tell you exactly what it is, because it's been discussed when we were voting. I'm going to find version. There we are. So the big issue is we don't say in the proposal which symbols you will find in there. It's implementation specific. But it's meant to tell you which library you have,

libcd C++ or libc++ or whatever, which version you have and everything. So the intent is to replace CISO646 with something that is more useful to C++ people and tells them what the tools they have on their hands are like version and kind of library so that you can adapt your client code to the do's and don'ts of your various tools okay so

that's a header that might tell us things but we don't know what it's implementation specific yeah okay now it raises the question for me of feature macros which last i heard had not been officially accepted but everyone agreed well almost everyone agrees is a good idea and it sounds kind of like something related stick to stick in there, yeah. I wasn't, I'm not the most knowledgeable one on version, but I think version is for the tools and libraries that you have, and feature macros are for the things that your compiler supports. Okay.

So you can do granular checks on support for concepts and support for modules and support for this with the feature test macros. And version is more, well, if you're using this standard library or that standard library and you do hacks based on which one you have, that's the place where you'll find the information. So was there any movement on feature macros then? I don't know. I've seen Clark Nelson. He was at the meeting at some point.

But feature macros didn't come into core, and I haven't seen any proposal for that pass by. I've seen it mentioned in the plans for Rapper's Will, so my guess is they're going to make a decision on that in a few months. My understanding

is that STL is a proponent of that, and I don't know if he was at Jacksonville. I've seen him. He was there. Okay. Okay, so you just mentioned Rapper's Will. So that'll be the next ISO C++ meeting. And according to the trip report,

it looks like that and then the winter meeting in San Diego are going to be the final meetings on major C++20 features. Is that right? Yeah, you're probably looking at Bryce's paper now when you're saying that. So we had an agenda that Herb brought to us, it's interesting, to give us a big idea on what the dependencies

were and what we are expected to provide. So yes, San Diego would be the place where the major language features will be completed, so we're hoping that the big ones are done by there. And we shouldn't be adding any more features past Kona. So what's called the winter meeting, it's November.

So I don't know if winter is the right word for that, but it's going to be November in San Diego, which should be pretty warm still. It's mid-fall and on the beach. Yeah, kind of. No, no. I've been to Kona twice. I haven't seen the water yet.

There's just too much work to do there. And the spring meeting in Kona is February or March 2019. We have Cologne planned for the summer and Belfast, which I'm looking forward to in November 2019. I've never been there.

It's an interesting city. I'm looking forward to that. So yeah, the thing is everything that goes through library evolution, we really hope it's done by the next meeting because then it has to move to library and they have to check it out and do the wording and the breeze always

overflowing with work because there's so much stuff going on there. So the evolutionary stuff, if we could get that through by Rapper's Will, it would be a good thing. So basically, one more meeting to try to get your major features done. Kind of, yeah. If they're not ready,

they better be very close to it. But there's hope, because the big things we hope, like coroutines, modules, concepts, maybe networking, if we're lucky, they're all pretty close. Okay. Well, it's been great having you on again, Patrice. We really love doing these trip reports with you.

You're very nice. I won't be in Rappersville, so you'll need to find someone else, but I should be in San Diego. Oh, no. Yeah, well, I'm giving a class in Shanghai at about the same date, so I won't be able to do both. Travel-wise, it was complicated.

Shanghai to Switzerland, long flight. No, but that would be easy. But the rules at my institution is that it has to be Montreal, Shanghai, then Shanghai, Montreal, then Montreal, Switzerland. That's what makes it senseless. Yeah, that's untainable.

No, at some point I have to go back home. So I won't be making this one, but I should be in San Diego. Okay, great. Thanks again, Patrice. Yeah, thanks for coming on. You're very nice. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving

and Jason at Leftkiss on Twitter. 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.