CppCast - Oulu Trip Report

Episode Date: June 25, 2016

Rob and Jason are joined by Herb Sutter, chair of the ISO C++ standards committee to discuss the latest progress on C++ 17 made at the Oulu ISO Standards meeting. Herb Sutter is a leading authority on software development. He is the best selling author of several books including Exceptional C++ and C++ Coding Standards, as well as hundreds of technical papers and articles, including the essay “The Free Lunch Is Over” which coined the term “concurrency revolution” and its recent sequel “Welcome to the Jungle” on the end of Moore’s Law and the turn to mainstream heterogeneous supercomputing from the cloud to ‘smartphones.’ Herb has served for a decade as chair of the ISO C++ standards committee, and is a software architect at Microsoft where he has led the language extensions design of C++/CLI, C++/CX, C++ AMP, and other technologies. News The ANTLR4 C++ target is here Jon Kalb speaks about CppCon, C++17 standard and C++ community Meeting C++ 2016 Talks Herb Sutter @herbsutter Sutter's Mill Links What the ISO C++ committee added to the C++17 working draft at the Oulu 2016 meeting Last chance for CppCon 2016 Early Bird Registration! Sponsor Incredibuild

This episode of CppCast is sponsored by Incredibuild. You won't believe how fast your build can run until you download your free developer version at incredibuild.com slash cppoffer or just click the link on our website. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now during early bird registration until July 1st. Episode 61 of CPP Cast with guest Herb Sutter recorded June 25th, 2016. In this episode, we talk about the Antler 4 C++ target. Then we talk to Herb Sutter, chair of the ISO C++ Standards Committee. Herb gives us a trip report from the ULU Standards Meeting.

Welcome to episode 61 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving. Joining me is my co-host, Jason Turner. Jason, how are you doing today? All right, Rob. How about you? Doing good. A little early for us, but we'll get by.

We've got a very special guest with us today, right? Yep. But before we get to him, I wanted to read a quick piece of feedback. This week, Brian wrote in, Hey there, I'm currently a college student and interning at a software startup company in Fort Lauderdale. I love your podcast, and I would love it if you guys did a podcast geared towards starting developers and what aspects of C++ to really focus on overall. For example, my professor drilled strong programming foundations and OOP principles into us, but what should I study or work on next to continue to develop my C++ skills? Thanks for your time. So it's definitely a good email. Thanks for reaching out, Brian. We haven't really done many kind of introductory type episodes yet, although we have had some younger developers who are doing some great things with C++.

That's true. So I'm not really sure where to go with this, but we'll have to think more about what we could do for more intro-level programmers. I feel like the closest we've gotten was when we talked about Stop Teaching C. Yeah, with Kate Gregory. That was a very good episode. Yeah. Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook or Twitter,

and you can email us at feedback at cppcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Herb Sutter. Herb is a leading author on software development. He's the best-selling author of several books, including Exceptional C++ and C++ Coding Standards, as well as hundreds of technical papers and articles, including the essay The Free Lunch is Over, which coined the term concurrency revolution and its recent sequel, Welcome to the Jungle,

on the end of Moore's Law and the turn to mainstream heterogeneous supercomputing from the cloud to smartphones. Herb has served for a decade as chair of the ISO C++ Standards Committee and is a software architect at Microsoft, where he has led the language extension design of C++ CLI, C++ CX, C++ AMP, and other technologies. Herb, welcome to the show. Hello, thanks for having me on. I didn't realize you had been chair for over a decade now of the C++ Committee. Yeah, I just recently realized the C++ Committee has been around for 26 years, and I've just passed the now over more than half the life of the committee mark. You just don't know where the time goes.

Time flies when you're having fun, and we've been doing a lot of stuff that's fun. You need to update that bio then. I guess, yes. It's a little dated. Yeah. Okay, Herbert, we just got a couple of news articles we're going to go through. Feel free to jump in and comment on any of these, and then we'll start talking to you about the most recent work in the standards committee, okay? Sounds good. Okay, so Jason, the first article is about the Antler 4 C++ target.

Do you want to talk about what the Antler library is? Yeah, Antler is a tool for generating parsers and it's, you know, it's a, it's been used by a lot of other languages, um, for a while for, um, making domain specific languages and that kind of thing. And I just thought it was cool to see that C++ is finally a target for it. We can play with some of the toys that the other kids have been playing with for a while. And this is specifically Antler version 4 that now has C++ target, but Antler 3 had one as well, right? I thought it was...

I'm sorry, maybe I got this news right. I didn't think Antler 3 did. I thought he was comparing Antler 3 C++ versus Antler 4 C++ in this article, so I thought that it was there for 3. Wow. And I think SeaLion, someone said in the comments that JetBrains uses Antler for some of their tools. Oh, that's cool.

Yeah. The next one is actually from Anastasia at the Sea Lion, and she's interviewing John Kalb about some of his work with the community and his opinions on C++ standards and things like that. It's always great to hear from John Kolb. He's really important to the C++ community. Yeah, John's a rising star. He's certainly been involved in C++ for some time, but he's just really making a place for himself in the community, and we all benefit from it with CppCon, with the training work he's doing now and it's just you know great to see these new people coming in it's not just

the old blood there's a lot of new blood in c++ these days john's definitely one of those yeah absolutely i mean it's amazing that he works on two conferences and and such spectacular conferences yes yeah and he also gave us a shout out too, which is always great. Well deserved. He's been a fan of the podcast since the first episode. Yeah. Yeah.

He's been a real great help. And then this last one is, uh, from meeting C plus plus, which is the big conference in Germany. And they haven't put out their schedule yet, but they did, uh, release a list of the talks that are going to be in that conference. Um, I was happy to see

that our recent guest, Jonathan Mueller, who mentioned that he submitted the talk, uh, seems like one of his made it. So that's good. Uh, were there any other highlights you wanted to call out in this one, Jason? Uh, I thought it was interesting that there are several articles on making sure you, or excuse me, not articles, talks, on making sure you understand your hardware that you're programming to. I noticed that Peter Sommerlad also was speaking on the C++ core guidelines

that Bjarnus Drescher pronounced at CPPCon last year, and that'll be a topic again at the conference in September this year. Kate Gregory is giving a tutorial about it. But starting to see some unification for the various C++ guidelines and using modern C++, that's really important guidance to the community. Yeah, absolutely. Okay, Herb. So today is the last day at the ULU ISO standards meeting. Has it been productive? It sure has. In fact, it's tiring as usual, but it's a good tired.

And we just finished. Oh, let's see. What time is it now? We just finished about one hour ago. So our final sessions, people are starting to head back to the airport. But we got a lot done. A lot of things were progressed by the hard work around the clock. So we saw on Twitter that the city of Ulu

threw a party for you guys for the Standards Committee. What was that like? Oh, that was a lot of fun. It was a nice social event where we went to the town hall, which was just a few blocks away from here. Beautiful, ornate building. And there was a nice standing reception with nibblers and wine. And it turns out a grand piano.

That Chandler Carruth of Google was the instigator in making sure the cover was taken off that piano, and it turns out that a number of committee members are players and even more are singers. And so it actually was a fun couple of hours after we'd already had a long day of work on Monday, and it was the only day that we didn't have a technical evening session where technical work was being done till the late hours of the night. So it was definitely a really nice start. And we appreciate Symbio and the city of Oulu to host us here. It's been a very productive week. It also helps that they deliberately did it the week of the summer solstice, where they have no night. night is canceled here it's south of the arctic circle but there is no official light but you just get to i think they call it nautical twilight for two

hours and then the sun comes back up again so it was hard to know when to go to bed yeah i was going to ask about that did you guys end up accidentally talking until two o'clock in the morning or something oh frequently i several times this week i looked at my watch and didn't realize it was up accidentally talking until two o'clock in the morning or something? Oh, frequently. Several times this week, I looked at my watch and didn't realize it was already midnight. And so I got to get to bed to update my papers and then go to bed and get up again for tomorrow. Oh, my goodness. So could you tell us a little bit more about the standards process for those of us who've never been to an ISO standards meeting? What exactly goes on? Sure. Well, we meet for six days, Monday morning through Saturday afternoon,

three times a year. And the beginning and end, so the first quarter day till morning break and the last Friday afternoon and Saturday afternoon are in plenary sessions. But that just means everybody's in the room. And we start some administrative organization Monday, and then we take the full plenary votes and straw polls on approving things that the subgroups did on Friday. But in between that, we're in subgroups most of the week, usually five, sometimes more subgroups meeting concurrently, library, library evolution, core language, core language evolution,

and the concurrency and parallelism groups are the ones that usually go all week long, and then there's a few extra ones usually that maybe meet for part of the week. And they work on individual technical topics as well as coordinate between themselves. So, for example, when in evolution, where I spend most of my time, we work on particular language features over the course of several meetings, and once they're in a form where we think yeah the design is right we've looked at the initial standard ease wording this is ready to go to core and then it gets sent to the core working group and if they have design questions they'll come back and ask it's a very well-oiled relationship right now and so the the

groups coordinate with each other and then then, of course, that may have standard library impact. So the library working groups also need to see what's coming. And so they can see how the standard library can be adjusted to take advantage of the changes coming in the core language. So that work is done in subgroups during the course of the week. And then on Friday afternoon, we get together and anything that's come up where we think now that the design and the wording is ready for inclusion, either in the C++ standard itself or in one of our side beta branches, our technical specifications, those proposals then recommendations come up to the full group. And then we discuss them and usually adopt them. Sometimes there's discussion where we think something's maybe not quite ready and please go back and try a slightly different direction. But generally, those get approved there and then they get applied for the post-meeting mailing by our hardworking project editors to update the working drafts and specifications.

It makes Friday sound like just I can't believe that that day ever ends when you're trying to coordinate all these things. Well, it's usually done in about three, four hours. But of course, especially last meeting and this meeting, because we were working on getting out the feature complete CD committee draft of C++17 for international ballot, which we did today, and it's going to go out for ballot over the summer. There's always extra work those last couple of meetings. And so yesterday, we started the afternoon session at 2.30. And on the agenda, as published, it said we'd be finished at 6.30. But we finished sometime after 7.30. But fortunately, the hotel held the dinner buffet for us. We sent out a messenger to say, please don't close it at 7.30. And so we still managed to get some food afterwards. So the breaking news there that you just let drop is that we do have a committee draft for C++17 finalized?

We do, in fact, have that. So that was the goal of the meeting, and we achieved that, as well as voting in some additional features in. So the idea here is C++17 is not done done, but we know it's feature set. It's feature complete. It's going to be sent out for its national body comment ballot period. And over the course of probably the next two meetings, November and then the Kona meeting in March, probably within those two meetings, we'll have sufficient time to process all the national body comments, process our own issues lists, our known bugs that we want to fix, and do other fine-tuning. And so then our plan is that hopefully at the Kona meeting – it might be at the July Toronto meeting, but hopefully at the March Kona meeting next year – we'll actually send out what could be the final ballot for C++17.

But the key thing is it's now going out for its main comment ballot. This is where the lion's share of all the review and commenting for people outside the committee will happen. And we get feedback from around the world, national bodies who don't come here in person, additional people from national bodies who do come, but who now have a larger set because, hey, this one's for real. Please look at this now. We think it's ready to go. Let us know what you find so we can address any bugs or issues or interactions. And so it's a major milestone for us now. And so this primary comment ballot is open season for review and then some more fine tuning for a couple of meetings or so, and then we'll be done with C++17.

If you're an average developer, but you're interested in being involved in the standards process, maybe you can't make it to one of the meetings, but how would you be able to give feedback in this question period? Oh, so formal feedback is done through ISO in their balloting system, but anybody can give feedback at any time by talking to standards committee members, by posting to the std-proposals and std-discussion forums. Those you can find on isocpp.org under the standardization and the forums tabs. The forums tabs tells you where those two forums are for proposals and discussion, and lots of committee members hang out there. Discussions welcome any time. And also under the Standardization tab, you'll see a page on meetings and participation,

as well as if you want to come in person, for example. We always invite observers, especially for meeting in your town, and also how to submit a defect report. And that you can do any time. You do not have to wait for the official ballot period to do that. And so you'll find the instructions there, isCPP.org, forums and standardization tabs. So I guess while we're on the topic of getting involved, what does it take to become a member of the Standards Committee? Well, that depends on your nation. You go to your national body where you or your company live and say, hey, I want to be a member. And they'll tell you whether they participate in our subcommittee at SC22, most do. And then they have their own instructions for how to get involved. In the United States, that's the PL22.16 is the acronym for the C++ Standards Committee for

the United States. And they have fees per company for participation, and there's a discount if you're an academic. But they also invite observers to come for a meeting or two, so you can come see if you like, and before you decide whether to become a member, the only difference is that you get to vote in the subgroups, but not at the plenary sessions. You don't get to raise your hand there, but you get to watch okay okay so maybe we can talk specifically about some of the uh have there been changes between jacksonville and ulu that we could talk about absolutely so in fact the best place to look run don't walk to go to bryce post on reddit which was posted yesterday okay very nice summary there of the things that we actually approved.

Nearly all four C++17, actually his list is all C++17, at this meeting, including a number of core language extensions and some libraries such as Variant, which made it in. And so we're quite pleased with that. That, again, when you look at that list, that's just the list of things approved at this meeting. There have been other things approved for C++17 at previous meetings, including the Jacksonville one.

And so, but here is just what's new as of our decisions in the last 48 hours. Looks like a lot of information up there. Yeah, I'm opening it up right now. So I guess one question I have, which I don't see specifically called out here, is do we have an operator dot overload consensus yet? The answer to that is almost.

That'll be in C++ post 17. So what happened there is that the proposal, which is for those who are not aware, it's for basically writing smart references, just like you overload operator arrow to make smart pointers. You can overload operator dot in this proposal to make smart references, which can be useful if, for instance, you want to dereference a shared pointer and get something that participates in keeping the object alive, not just a raw reference. That almost made it, but a last-minute technical problem was found where there was an interaction that couldn't be solved at the meeting. And I believe the proposals, the authors voluntarily withdrew it. They may have an updated paper with a solution for that problem as soon as two weeks from now when the post-meeting

mailing goes out, or if failing that over the summer. So it's definitely not dead. It's still coming, but it didn't just quite make it because a last- minute glitch was found. So we took it off the countdown list. It seems like that's just an astounding amount of coordination. Like I already said, everyone trying to find these flaws or approve or disapprove of the proposals and make sure that you don't break anything that's currently in the standard existing code. It sure is. And just to give you an idea of the scale of that and also the success with, I'm just really pleased with seeing how the committee is working on this, is compare the C++98 standard for those who've been around long enough to see that, I was there for the tail end of it, with what we're doing now.

We sent out two committee drafts for C++98 and then two other ballots. None of those four, including the final ballot, were as high quality as this document is for just, air quotes, just a committee draft, an inquiry draft where we get an initial set of comments. Never mind the fine-tuning we're going to do over the course of the next couple of meetings here or so. And that's a direct result of the work that's been done by the committee members, by the core working group, by the library working group, those helping them to continue to make sure that we keep bugs under control. That as we're adding things, we think about interactions. And that's certainly not guaranteed. As you just throw stuff in a pot, you could get, if that's all you do,

you can get a lot of interactions and failures. And oops, I didn't notice that until five years later, and the user trips over it, a landmine that you put in front of them. There's very little of that. And that's a very strong statement about the level of quality. Sometimes it's frazzling to stay at that level of quality, but the committee does a very good job at that. And one other thing that contributes to that is that some of the larger extensions are floated out, as I mentioned, in beta branches, so to speak, or technical specifications,

their own specifications separate from the standard before they're integrated in the standard. So for example, we did that with the parallel STL work that was done as a separate technical specification. And at the previous meeting to this one, so three months ago, we voted that into C++17. So it's in C++17. But in the meantime, people have had a chance to implement and try out that specification. And we voted some tweaks to that based on that usage experience at this meeting. And that's helpful because before you cast a feature in stone in the standard, where it's going to be very hard to take a breaking change if you discover you made a mistake, it's much easier to get experience off to the side in an experimental namespace,

std colon colon experimental. And then if you discover a problem, okay, even if people are already starting to use it, now you can take the breaking change as it comes into the standard. And then users who are already using the beta versions of it, those implementations out there, they know they're getting the std experimental, the TS semantics while they're using that, you're not breaking them. And then as they're ready to transition to the standard version, they can take that change and accommodate that change in semantics or whatever it is that was a breaking change when we fixed something. That greatly reduces the stress of having to put something in the standard and know that it's really truly perfect

because we're not going to get to take a breaking change very easily forever. That has really helped relieve the stress. So those things play into the ability to do a lot of this work and see this advance at high quality. It's an important thing, I think, to remember is all three of the major compilers right now

are supporting some aspects of proposed C++ 17 that you are working with things that, yeah, it's, it's pretty cool. Yeah. We were just talking to Andrew Pardo last week about some of the changes you could get in visual C++,

like the new version of modules and, and co-routines. Very exciting stuff. And, and those are two good examples of those separate technical specifications. So modules is already underway. There's at least one implementation already,

and I believe one, possibly two more coming. And then coroutines already has an implementation. And the only reason we didn't vote to officially create a technical specification draft for coroutines based on that work at this meeting was simply because we prioritized doing the wording review for the things going into C++17, and we did all of that, but we ran out of time to look at some other things, and so we're going to do follow-up with that.

That doesn't mean they're dropped on the floor or there's lack of interest. That's going to happen at the next meeting, which is going to be at the Issaquah in November. But we were very much in all the groups prioritizing C++17 work for this week. We did other stuff too, but if push came to shove, that's what took priority. So one of the things I saw Chandler and Elister tweeting about yesterday was this order of evaluation for expressions. And I honestly got a we should add the order of this to this being doing a function arguments when you call a function F, a comma, b comma, c, that you evaluate a full stop, then be full stop, then C. That was the only part that we decided wasn't as important. It didn't fix as many bugs, and people generally shouldn't be relying on that. We can still reserve the right to go back and decide that we should do that after all next time. But we did all the other parts of the order evaluation of expressions. So for example, let's see if we can do this verbally in words without a whiteboard and a screen.

It is a longstanding known feature that if you have a function that takes two smart pointers, can be unique pointers, shared pointers, doesn't matter what it is, as parameters. And if you call that function with call my func, open paren, new t, comma, new t, paren, that until now in C++, you are just asking for a leak. Because if an exception is thrown after you evaluate one of those, but before you fully evaluate that you construct the smart pointer argument that it's passed to, then you could have a leak because the language rules work out that you don't call delete necessarily in the right place as if an exception is thrown. If you want to know the details, look up a guru of the week that I wrote about that, oh, some 20 years ago. And the problem comes because not the arguments aren't evaluated

in order, but that they are interleaved, that you could evaluate new T and new T and then go back and construct the one shared pointer argument and the other shared pointer argument. And if you do it in that order, then if the second new T throws, you leak the first one. That bug is gone. Even though we're not saying you do the entire arguments left to right, we do say you can't interleave them. So that bug just disappears. Another bug that disappears is in the concurrency TS that we have that's, again, separate from C++17, but it's in parallel, so it'll be in the next standard very likely. It includes future.then, which is great for continuations, and you can chain those. So it's very common once you have future.then to write future.then my lambda, dot then my lambda,

dot then my lambda, and you get asynchrony at each of the dot thens, which can be non-blocking calls or blocking calls, or you can get asynchrony and interleaving. Well, the problem is that the language didn't actually say that those would be evaluated in the correct order. So until yesterday, future.then chaining was broken. So were examples in Bjarne's book that were peer-reviewed by many committee members over six editions or six reviews or something like that. And basically, the order of evaluation boils down to now the language does what you thought it did. And all the key places that caused pitfalls, that caused buggy code, all of those have been fixed. And we might still go further, not just with the arguments that I mentioned, but perhaps with a few other things.

But we nailed down as much as needed to be nailed down to fix the common sources of problems so that your code does what you thought it did. And you know what? We don't mind invalidating a pitfall section of a book from time to time. That's progress. That's a good thing. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. IncrediBuild dramatically reduces compilation and development times for both small and big companies like EA, Microsoft Game Studios, and NVIDIA.

IncrediBuild's unique process virtualization technology will transform your computer network into a virtual supercomputer and let each workstation use hundreds of idle cores across the network. Use IncrediBuild to accelerate more than just C++ compilations, speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly developer hours using existing hardware. Download your free developer version at incredibuild.com slash cppoffer, or just click on the link in our link section.

So you said that you focused on C++ 17 standards features but can you tell us about any of the work that was done in some of the ts's uh was there any progress made with ranges there is some progress made with some of the ts's but not as much as at most meetings because our focus was on c++ 17 ranges did get some review they have a new working draft. So did the graphics technical specification for 2D graphics. That got additional review. And coroutines did not end up getting a review because they were in – the review would be by a group that was swamped with C++17 stuff. So depending which group you're in, then they – if their schedule wasn't full of C++17, you got more review. We did make progress on several of those,

but expect a return to form with full-speed progress on those again starting next meeting now that we have this one under control. Of course, having said that, the next two meetings also will be doing issues resolution, ballot comment resolution for C++17, but that's generally not quite the fire drill of getting all the features in in the first place, and especially because those features are already at good quality, because the wording review that's been done so far has been at high quality. That's less of an emergency, so expect more of a return to form to those. But we did make progress on some of them, including ranges and graphics. One of the core features I'm personally interested in is reflection.

And I didn't notice any news saying if there was any movement on that. There is progress behind the scenes. So behind the scenes meaning it hasn't reached the core, the main groups like Evolution, Library Evolution yet. But they actually did meet for a long evening session on Tuesday, I believe it was. So they were there until like 11, 11.30 and looking at the latest updates on the reflection proposal. And the previous meeting was the first time that one of the competing proposals got consensus and got in that small group, at least that, hey, this is the direction we want to go, and it's promising. And so we got an update to that proposal, and it was seen by an even larger

group, and I attended that session as well. And that's moving forward. There was one particular issue that was raised for feedback. What do you do about things that don't have names, such as type defs or anonymous unions and things like that, which some might think are, well, that's a corner case. I never use an anonymous union. But you need answers for those things. And you do use type defs. And if you want to reflect on something, do you want the name of the type def that you're using as the name at that line of source that you're using to refer to it? Or its real name, the way it was declared, which is equivalent, you probably want both of those. And so there was progress. We liked much of the

progress already seen. That was the major part where we asked for more improvement. So I expect that one to continue making progress. And we've been looking forward to seeing a draft maybe enter the main working groups in the next few meetings. I think the average person who wants reflection, including myself, would have just thought, well, just give me a list of classes and functions that are there and wouldn't have stopped to even think about something like that. Yeah. And then the question is, do you want to reflect on templates? What do you do in the presence of overloads? And what about default arguments? Should you be able to reflect on those as well? And so you have to think about the whole language. So one of the tempting things with any feature is to look at the feature and the 90% case. Hey, here's 90% of the cases the feature covers,

and that's all I care about. In fact, I just care about a very basic use case. But even if that's all you care about today, you're going to try to use it for something more tomorrow. We better have said correctly what it does and have compilers agree on what it does. So it's not like, well, GCC decided you'd probably want it to do this. And Visual C++ thought, no, this is much better. So we try to anticipate those things as we go. Right. I don't think we've talked about the graphics TS at all on the show before. Could you give us an overview of that? What they're trying to accomplish with it? Sure. The idea is to have basic 2D graphics available so that you can do in a portable

C++ code, do basic output. We've had the IO streams so that every Hello World program that we've ever been able to write, we just say, oh, look, int main, pren pren, open brace, see out Hello World, and you're done. What does that mean on a phone? What does console IO mean when there's not necessarily a console? Right. And so, as we are now in a world that's different from when Hello World was introduced, and most notably with Dennis Ritchie and the initial C programming language book, when there were consoles where everybody knows what a console is, that's what you see in front of you as you interact with a computer. Yeah, maybe, and maybe not these days. That hardware

target has moved. And so it's important to be able to put even something basic, and certainly this goes beyond what's just basic, in front of users in portable code without resorting to non-portable libraries. And so the intention there is to do something that has initially started by wrapping the Cairo API, a subset of the Cairo API, and elevating it to a C++ style. It was a well-written OOC style and make the C++ style around that. And it's evolved further since then. But use that to be able to show in a standard library, here's how you interact with a 2D drawing surface and with brushes and with things like that. And the hope is too that many of the popular graphics packages, including Cinder and OpenFX and different ones like that, would potentially be able to remove the proprietary custom stuff that they have as duplicates in each of their libraries and just say, oh, now we can use this standard one instead of having this basic foundational layer

duplicated by hand and with slight differences and variations that people have to deal with as they use the different packages. Makes sense. Yeah, it sounds pretty exciting. Is it something that 2D game developers might be able to use on its own, or would they still prefer to use something like Cinder, maybe? Well, it's certainly something that game developers, if you're a professional game developer, you are very likely doing something non-portable anyway. You can write a lot of

portable code, sure. But when you talk to the actual graphics system, you are very likely going to do something that's specific to that. Now, a little casual game here and there, we'll be able to write those in portable code once we have this TS. But if you're doing something like a serious game, of course, you're going to do non-portable things anyway. The hope here is that for people who aren't necessarily doing a serious game but who want to program a small game or who want to just get something up on the screen or show a graph or show an animation or just show something that can be displayed on a surface without a console, then they'll be able to do that in portable code without resorting to, okay, first I have to Google for what are the graphics libraries available for C++ these days and start learning their documentation, and then it's different for the next one if they have to move. I just noticed that structured bindings was approved

according to that Reddit post you mentioned. That's pretty exciting to me if I'm reading this right. Yeah, that was post you mentioned. That's pretty exciting to me, if I'm reading this right. Yeah, that was a happy surprise. So this essentially, I mean, to the average user, what this basically means is that we can return multiple values from a function. Would that be a fair way to put that? Pretty much. It sort of completes the being able to return multiple values from a function. C++ doesn't support that fully directly, but we already have cases in the standard like set insert that returns a pair.

It returns a bool, did it work or not, true or false, and oh, by the way, and here's an iterator, if it did work, pointing to the element you just inserted. And we already had something in C++ before this, a library function stood tie, std colon colon tie. And what that did is if you already had a bool variable and an iterator variable, b and iter lying around, you could say tie open paren b comma iter close paren equals set dot insert. Well, that's fine if you already had those variables lying around. And then you could, instead of saying the return value dot first, return value dot second, you could say b and iter. If b, use iter. And it was much nicer. The only thing we didn't have is if you didn't already have those variables lying around. And so what this feature does is it creates names in your scope where you can just call, say, auto, open square bracket, b, iter, close bracket equals set.insert. And now you can say if b and use iter, and it gives you those names in your scope. And under the covers, what it does is it works for something that returns a tuple or a pair or a struct with all public data members.

And there's also a way to customize it for your type if you don't fall in those two categories. But what it does under the covers is it returns the function, as always, returns a copy of the tuple or struct that contains those values. And the language will just store a copy of that silently on the stack as a return value, and then create these names as if references. So think of them as references to the members of that structure tuple. They don't have to be references. Think of they're just really new names for those things, convenience names for those things. And then you can go ahead and use those. And it's very convenient for your code. You don't have to

create random extra local variables that aren't initialized because now you're going to initialize them after that using tie and the return value. It just makes it easier to use those functions and more convenient to use a multiple return value style by returning a struct or a tuple. I noticed leading up to this meeting that it looked like there was a couple of different proposals for whether it was going to be angle brackets or braces or square brackets or how you're going to do the destructuring. I'm curious if you know what the thought process was while you settled on the square brackets. Yes, actually, my name was on that proposal. I was the main author of it,

but also with Bjarne Strostrup and Gabriel Dos Reis. And Jens Maurer helped incredibly with the core language standardese wording. I'm glad he drafted it and not me because he would have just had to go fix it again. And so Jens is just an invaluable committee member for that kind of thing. He's very civic-minded and helpful and expert. But what happened when we discussed it in evolution at our previous meeting in Jacksonville, we took a poll on the curly braces which we, the authors, proposed and, frankly, still like better. Versus the, hey, just saying. But we're also happy with the square brackets that helps parsing in some ways, or at least the fear was that the curly braces might lead to more difficult parsing

or connote the wrong thing. Well, when there's a discussion like that, you have discussion, and if it's not clear what the direction of the evolution group is, then the chair, Vile Votilainen, who was also our host here this week in Oulu, he last meeting took a poll and said, all right, how many of you like this? Should we move this forward as shown in the paper with the current Bracely syntax? And then he took another poll and said, well, what would you think about moving this forward but with the syntax change to square braces, square brackets?

And there was considerably more support for the square brackets. So we took that as the evolution working group's direction, updated the paper and the wording. That's what we brought forward here and got approved. Wow. Well, I'm happy to see it approved. I did not find the previous solution of using tie satisfying. Yeah, it's perfectly satisfying and fine if you already have the variables lying around. But if you don't, and often you don't, then it turns out that you want some language support for that. Having said that, Reddit immediately figured out that this overlaps with another feature, which was a surprise that it made it so quickly at this meeting. I was not expecting this proposal to slip in under the deadline in 17.

It wasn't even clear it would get consensus, but it did. And that's the one that if you're looking at the Reddit post, it happens to be mentioned next. And it's the one that says, just like in the for loop, you know how with the for loop, there's those three parts, there's the initializing those for loop scope variables part, then the condition, then the increment. So for int i equals zero, semicolon, and then the rest. And that i has lifetime for the scope of the for loop. Well, sometimes you want that for if and switch, and now you can do it. So if and switch have now grown the same. In fact, it's grammatically exactly the same.

The initializer, if you want to put it with a semicolon, just like with a for loop, that you can put in front of the if and the switch. And that's very convenient if you want to have a variable whose lifetime is only for the scope of the if. You only need it inside the if, possibly in the true branch or the false branch, the else branch. But you don't need it after that. Well, today you have to create the variable outside the if so that it lives long enough, and then it lies around polluting the rest of your function scope, even if you didn't need it. And if you needed it, that's fine. Keep doing that. But often you don't. You just wanted it for the scope of the if or the switch. And so now you can just go ahead and declare a variable and initialize it for the scope of the if and the switch, just like we always could with for

since the days of C. So Reddit took about 30 minutes to figure out that you can do structured bindings for that initializer, and showing nice examples of where you can do if auto bool b comma iter equals set dot insert, and then if b, if it did insert, then in the true branch, use the iterator. It really is nice how those features work well together. And so I'm looking forward to using that in my own code. That sounds pretty cool, yeah. Do you get a lot of good feedback over the internet? I guess you probably didn't get any of this 10 or 15 years ago the way you do now.

Not as much, although back in the days of Usenet, anyone remember Usenet? It still exists, actually. You look from time to time and it's still there with some of the same names I recognized from the 90s, actually. Rob's too young for that. That's another topic, right. But Usenet, which was basically very much like Reddit or before it and the other web forums that have existed, was a place where people could have essentially glorified public mailing lists that people could post to and have discussions on. And one of those comp langs, C++ Moderated, where I was a moderator. Yeah, I'm really dating myself now.

And the comp-STD C++ were places where a lot of discussion happened and we got a lot of good feedback. Of course, those were also the days where, and I am not making this up for those of you kids at home who think that I am. That's the day when the committee sent out all the papers that were written for each meeting as paper mailing, where you would actually get a box of 1,000 pages, like a ream box, sometimes two ream boxes, that you would put in your suitcase and carry with you to the meeting. Fortunately, I just missed that part myself, and the committee was well into electronic document distribution by then, but it was still available as an option. We only canceled that years after I started joining. But yes, you got feedback, but things were harder in those days. And certainly things are very elegant now. And we're very glad to be able to share progress on Reddit. And this Reddit post was being updated in real time as the meeting was happening,

as each motion was approved. So we certainly have a better set of tools for interaction and we appreciate that. So I want to talk a little bit about an internet reaction to C++17 after Jacksonville. Obviously a lot of developers were a little disappointed that features like modules and concepts didn't make it in. Do you think they will make it into the next version, whether that's C++ 20 or something else? I think the answer is very likely yes. You can't predict anything in advance with certainty. But yes, the next standard after this is expected to be C++ 20.

We're now on a three-year release cycle where we're shipping on a train model. A train leaves the station every three years. And so far since we'd started doing that in 2011, the trains have run on time. We shipped on time in C++ 14, which was the first time we ever shipped a standard when we said we would. And we're now on progress, on track this week to do it exactly right again for C++ 17. This was the critical meeting. If we had delayed here, that would have pushed things out. There's very much less pressure to delay in comment resolution, ballot comment resolution.

So I think it's safe to say now that we're on time again for C++ 17, and so we expect to be on time for C++ 20 again. And that's the next time the major revision of the standard would be. Certainly many of the things that are available in TS form now, including concepts, including the first concurrency TS, perhaps ranges. It's well on its way, but we're not done with that one yet. That one's still in progress. Whatever of those beta branches are done and shipped and have had time to get some experience, no doubt will be proposed again.

In fact, I was just talking with somebody, a committee member in the court, or after our session ended today. He took me aside saying, by the way, this is a heads up. I plan to propose feature blah from a TS as soon as we ship C++ 17. And I said, great, looking forward to it. I expect that to happen. And so no doubt that will begin already next summer

as we open up the next standard and start doing work on C++ 20. And certainly if you look at – let me refer your viewers, readers, what are they? Listeners. Listeners. To the isocpp.org page. If you go to any place in isocpp.org,

look on the left-hand side for current status. Just click on that, and you will see there a link for all the work we're doing, including all the TSs that are in flight, concepts, concurrency, networking, library fundamentals, parallelism, ranges, modules. And that's not a guarantee that all of those will land, be finished on their own streams, and have time to get experience for C++20 in a way that will satisfy everybody that they're baked enough to put into the main standard and basically merge into trunk. That's the way to think about it. But certainly some of them will be. And I won't take predictions right now, and I won't take any bets as to which ones and how many. But certainly you would be betting very

wisely if you bet on the ones that were finished sooner, such as concepts and concurrency, to have a much better chance of making it in. In fact, as you probably know from Jacksonville, from our previous meeting this March, we already saw something like 40% or so. I'm not remembering exact percentages right now, but a large minority of the committee was quite ready to vote it into C++17. So unless some surprise is encountered, I would expect that to monotonically increase with the passing of each meeting in each year. So some of these I would almost say are slam dunks for the next standard, but it's always safer to wait and see and then report on what actually did happen rather than speculate. So is there anything else from this past meeting that you would like to call attention to that we haven't brought up yet? Well, there are several nice additions.

And let me just get a list that I had here recently to remind me. So we talked about order of expression evaluation, which is great for fixing a bunch of bugs. We talked about structured bindings and if and switch initializers, which are like peanut butter and jelly. They're even better together. We also had some smaller stuff like forward progress guarantees for parallel algorithms that will be beneficial if you're using those parts of the standard. But going back to a few things that probably everyone will find useful, one was deducing template arguments for classes and also for constructors. So today, if you call it a function template, like an STL algorithm, like sort, you don't have to say it's template

parameters because you can deduce from the arguments you're given, well, I can see what type that is, Mr. Compiler. You don't have to have me tell you again what its type is. You can see what the argument is, and we deduce it. So we've had template argument deduction for function templates for a long time. But what we haven't had is the same thing for constructors, so that if you create a pair from two integers, you still had to say until now, pair open angle int comma int close angle my variable name equals one comma two. Well, now you can just say pair p open brace one comma two close brace semicolon, and you're done. And we deduce, oh, those are two ints. We know which constructor you meant. In fact, we know which type you need for that pair. And so that's certainly going to make life easier. And I gave some examples of that in my trip report blog post from three months ago,

pointing out that this was a feature that we expected still to come. And in fact, it did land. So you can see there for more. And another one that was probably going to be widely viewed as helpful, especially for library authors, is if constexpr. It is disguised as constexpr if on the page, because that's what the original proposed syntax was. But now it's just if, just like a regular if statement, but you can say the word constexpr in front of the expression. And what that means is it's compile time, and it's guaranteed to be evaluated

at compile time. Furthermore, you can have an else as well, of course, and a cascading set of else's and if constexprs if you want. All of those are guaranteed to be done at compile time and only the branch taken will be evaluated. Now, I want to make it clear that this is not the same as the feature in some other languages because it is not just free-form text inclusion. Each branch must be well-formed on its own. You can't just use this to arbitrarily muck with the language or do things that are kind of undisciplined. It is more disciplined than the feature you might see in other languages, not just basically glorified macro text substitution, where you can sort of use it to make half a statement. It won't do that. But for disciplined uses, which are robust and

maintainable and still very flexible, if constexpr is a compile-time if that will let you do a lot of things. For example, let's say you're writing an algorithm, and you want to specialize it for random access iterators. Well, today what you would do is you'd write the base algorithm that would work for any kind of iterator, say bidirectional, but it would do the slower thing you do if you can't do random access, and then you specialize it for random access. Well, now you can write the algorithm once and simply say, oh, if I'm given a random, if constexpr, this is a random access iterator,

do it the fast way, else do it the slow way. And that just leads to cleaner, more maintainable code. I didn't need to re-specialize the template. I could hide that implementation detail, which I can still document to tell users about. But now I didn't have to advertise it as part of the interface of my function just because that's how I had to shoehorn that in. And in fact, one of the nice things about if constexpr, when you combine it with other language features, like for example, the auto return type, where you deduce the type that's returned from the function, which is fine if you have an inline function. Well, now, if you have used that existing feature we already had since C++14 of an auto return type, and you now,

in the body of that function, use if constexpr, which returns different types on different branches. Now, think about that for a moment. You have a, which returns different types on different branches. Now think about that for a moment. You have a function that returns different, completely unrelated types on different branches. As long as they're in different if constexpr branches, that's just fine. And auto will deduce the correct type depending on statically which of those branches you decided to take. That's pretty sweet. And that leads to cleaner, more maintainable code that is still type-correct, still type-safe. We're not conflating types.

You can't do inconsistent types in the same branch. But you can in separate branches, and it does what you would expect. So that's pretty cool. I can see using that. So one thing I wanted to end with is that this is the last week where you can sign up for the CPPCon early bird tickets. Is that right? Oh, that is correct. Run, don't walk. There's no limit, but we're already seeing more than ever before at this point, this far in front of CPPCon. So it's going to be bigger than ever this year. And we're really looking forward

to it. And having had a sneak peek, we haven't published the program yet, but since I'm one of the organizers, and I've seen all the session submissions come through, we've had to reject not quite half of them, just because there's no room. We have six tracks for the whole week, over 100 sessions, and there were nearly 200, I think it was like 184 or something like that, session submissions, nearly all of which were high quality. And it just hurts to see some of the ones we had to cut, but that just means the ones that are accepted are even better. That list will be posted in about three, four weeks, so after early bird. But those of you out there who trust us on the agenda, you've seen the high quality of the previous two years, which are available on YouTube and professionally recorded,

you get your early bird discount. But if you want to wait and see what the sessions are, those will also be available in mid-July. And, you know, it's looking to be a really good conference again this year. And one problem with having so many good sessions is that you can only watch one at a time live on the six tracks and the rest you watch on YouTube later. But it's really useful to be there, see the atmosphere, interact with other attendees. And it's really the C++ Festival of the Year.

So I'm really looking forward to it. Do you have an expectation for how many attendees we might have this year? I'll know more as we get closer to the event. We had the better part of 1,000 last year. So we were in the mid-high hundreds last year. So I'm looking forward to a really fun conference. And we still haven't outgrown the Maiden Bower Center. So same location as last year. Excellent. Last year, you and Bjarne did some big keynote talks about the core guidelines. Do you expect that'll be another big topic of discussion this year? Well, I know Bjarne is giving the opening keynote.

Gregory is giving a whole two-day tutorial on the core guidelines the Saturday, Sunday before the conference. Those are a set of tutorials you can register for separately. They're separate tickets for those who would like to take advantage of that at the conference. And then the conference runs Monday to Friday with the regular sessions. So definitely there will be content about that. Neil McIntosh, I believe, is likely to give some talks showing the updated Checkr implementation. He's the guy who was on stage with me in my plenary session last year doing the live demos of the prototype that we had made up to that point. So depending on what the program committee decides for what the final talk list is, we'll see.

But certainly Kate's giving that two-day tutorial, and I expect to see more about not just those core guidelines and that checker tool, but analysis improvements in general, client-tidy and what it's been doing. And we're getting a really nice tools ecosystem going, and it's really nice to see. There's lots of motion and lots of news to see about the community, and that'll be reflected in the program. Okay. Well, Herb, thank you so much for your time today.

Thanks for coming on the show. People can find more information about you on your website and, of course, at the isocpp.org website, right? Absolutely. Okay. Thank you so much for your time. All right. Thanks for having me. And congratulations again on this podcast. Love to see what's happening here. Thank you. Thank you.

Thanks so much for listening 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 that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. 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.