Two weeks ago, I gave a talk at ACCU based on my paper P0709. The talk video was posted today:
Thanks again to ACCU for inviting me and recording the talk, and for all the fun interactions and conversations with everyone at the conference!
Two weeks ago, I gave a talk at ACCU based on my paper P0709. The talk video was posted today:
Thanks again to ACCU for inviting me and recording the talk, and for all the fun interactions and conversations with everyone at the conference!
A few minutes ago, the ISO C++ committee completed its winter meeting in Kona, HI, USA, hosted with thanks by Plum Hall, NVIDIA, and the Standard C++ Foundation. As usual, we met for six days Monday through Saturday, including most evenings. This and the previous meeting were the biggest ISO C++ meetings in our 29-year history, and this time we had a new record of 13 voting national bodies represented in person: Bulgaria, Canada, Czech Republic, Finland, France, Germany, Netherlands, Poland, Russia, Spain, Switzerland, United Kingdom, and United States. For more details about our size increase, including how we adapted organizationally to handle the load, see my San Diego “pre-trip” report and my San Diego trip report.
Thank you to all of the hundreds of people who participate in ISO C++ in person and electronically. Below, I want to at least try to recognize by name many of the authors of the proposals we adopted, but nobody succeeds with a proposal on their own. C++ is a team effort – this wouldn’t be possible without all of your help. So, thank you, and apologies for not being able to acknowledge everyone by name.
Per our official C++20 schedule, this was the last meeting to approve features for C++20, so we gave priority to proposals that might make C++20 or otherwise could make solid progress, and we deferred other proposals to be considered at a future meeting — not at all as a comment on the proposals, but just for lack of time at this meeting. (I’ve been holding back from publishing updates to my own P0707 and P0709 proposals, generation+metaclasses and lightweight exception handling, for this very reason.)
So we now know most of the final feature set of C++20! At our next meeting in July, we expect to formally adopt a few additional features that were design-approved at this meeting but didn’t complete full wording specification review this week, and then at the end of the July meeting we will launch the primary international comment ballot (aka CD ballot) for C++20.
Again, I want to acknowledge the primary proposal authors by name, who did a lot of the heavy lifting. But none of this would be possible without the hard work of scores of people at this meeting and over the past few years including in alternative proposals.
Modules (Gabriel Dos Reis, Richard Smith) was adopted for C++20. Modules are a new alternative to header files that deliver a number of key improvements, notably isolating the effects of macros and enabling scalable builds. As I’ve said in talks (another example), I personally find this feature very significant for several reasons, but the most fundamental is that this is the first time in about 35 years that C++ has added a new feature where users can define a named encapsulation boundary. Until now, we have had three such language features that let programmers create their own Words of Power by (a) giving a user-defined name to (b) something whose implementation is hidden. They are: the variable (which encapsulates the current value), the function (which encapsulates code and behavior), and the class (which encapsulates both to deliver a bunch of state and functions together). Even other major features such as templates are ways to adorn or parameterize those three fundamental features. To these three we now add a fourth: the module (which encapsulates all three to deliver a bunch of them together). That’s a fundamental reason underlying why modules enable further improvements that can now follow on in future C++ evolution.
Coroutines (Gor Nishanov) was adopted for C++20. A number of other authors that have their own coroutine proposals have also done great work to give feedback to this design and inform the committee in the process of showing their own designs, and the adopted coroutines design is expected to adopt some of their additional programming capabilities in the future as well as we continue to build on it after C++20. At this meeting, we had many detailed design discussions, including notably these papers that will be available in a few weeks when the post-meeting mailing is posted: a unified consensus report from all coroutines proposers describing the strengths and weaknesses of all their proposals, and a consensus report from implementers from all major C++ compilers about the tradeoffs and feasibility of the basic facilities required by the various coroutines proposals. Both of these papers are very educational and highly recommended.
A number of other smaller changes were adopted as well.
Several other features were design-approved for C++20 this week but did not yet have their specification wording reviewed to merge into the working draft at this meeting, and they are hoped to be formally adopted at our July meeting in Cologne. These include things like text formatting, flat_map, more ranges and algorithms such as move-only views, an automatically joining thread with stop token support, and more. I’ll cover which of these are actually adopted in my July trip report, when we know what landed at that meeting.
Now that we are close to knowing the final feature set of C++20, we can see will be C++’s largest release since C++11. “Major” features include at least the following:
Combined with what came in C++14 and C++17, the C++14/17/20 nine-year cycle is arguably our biggest nine-year cycle yet alongside the previous two (C++98 and C++11) in terms of new features added. We understand that’s exciting, but we also understand that’s a lot for the community to absorb, and so I’m also pleased that along the way we’ve done things like create the Direction Group and, most recently, SG20 on Education, to help guide and absorb continued C++ evolution in our vibrant living language.
Executors and Networking: Both of these continue to progress together, as Networking depends on Executors. We had hoped that part of Executors might be ready for C++20 but they didn’t make the cut, and both of these are now on track for soon post-C++20 (i.e., early in the C++23 cycle).
Reflection TS v1 (David Sankel, Axel Naumann) completed. The Reflection TS international comments have now been processed and the TS is approved for publication. As I mentioned in other trip reports, note again that the TS’s current template metaprogramming-based syntax is just a placeholder; the feedback being requested is on the core “guts” of the design, and the committee already knows it intends to replace the surface syntax with a simpler programming model that uses ordinary compile-time code and not <>-style metaprogramming.
Generic Scope Guard and RAII Wrapper for the Standard Library (Peter Sommerlad, Andrew Sandoval, Eric Niebler, Daniel Krügler) was adopted into the Library Fundamentals 3 TS.
Thank you again to the approximately 180 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good spring… our next regular WG21 meeting in July (Cologne, Germany) where we plan to send out C++20 for its major international review ballot, then spend two more meetings responding to those review comments and make other bugfixes before sending final C++20 out for its approval ballot one year from now.
On Saturday November 10, the ISO C++ committee completed its fall meeting in San Diego, California, USA, hosted with thanks by Qualcomm. This was the biggest ISO C++ meeting in our 29-year history, with some 180 people at the meeting, representing 12 nations. For more details about our size increase, including how we adapted organizationally to handle the load, see my “pre-trip report” posted before the meeting began.
Because this is one of the last meetings for adding features to C++20, we gave priority to proposals that might make C++20, and we adopted a number of them for C++20. Thank you to all of the hundreds of people who participate in ISO C++, those who came to the meeting and still more who participated electronically, and who all helped with the design refinement and specification wording and organization. I want to at least try to recognize by name many of the authors of the proposals we adopted, but nobody succeeds with a proposal on their own. C++ is a team effort – this wouldn’t be possible without all of your help. So, thank you, and apologies for not being able to acknowledge everyone by name.
The committee is actively working to keep coherence and direction in the face of a tsunami of proposals and a huge number of enthusiastic people. Perhaps the most impactful record-setting number was the size of the pre-meeting mailing: 274 papers. For comparison, even excluding the biggest paper which was the updated C++ standard working draft which appears in every mailing, the pre-meeting mailing was enormous:
We appreciate all the input, including that many of the papers are about bug fixes (always welcome) and rounding out existing features. However, a large number were proposals for new “good” features. And the trouble is that we can’t say yes to every feature that is “good” that benefits some users; we have to decide on a focused set, of at least coordinated features and ideally of general composable features, that fulfills the aim and mission of C++ and keeps the language adoptable and usable.
As I reminded in my pre-trip report, focus means saying no more often, and so we’ve taken several steps in recent meetings and at this meeting:
Ranges (Eric Niebler, Casey Carter, Christopher Di Bella) was adopted for C++20. This was a tremendous amount of work by Casey Carter in particular (witness the recurring 3:00am editing update emails during the week). As Eric Niebler put it: “If you liked the Ranges TS, you’ll love C++20.”
Concepts “convenience” notation for constrained templates (Ville Voutilainen, Thomas Köppe, Andrew Sutton, Herb Sutter, Gabriel Dos Reis, Bjarne Stroustrup, Jason Merrill, Hubert Tong, Eric Niebler, Casey Carter, Tom Honermann, Erich Keane, Walter E. Brown, Michael Spertus) passed unanimously on Saturday. I highlighted this paper as a “we may have a winner here” in my last trip report, and indeed it sailed through and was adopted for C++20. Recall that we already added the concepts core feature to C++20 back in 2017, but without the convenience notation to write templates without the “template” or “requires” keywords; at this meeting we finally converged on a convenience syntax to write constrained templates that both addressed all the major problems people had identified in the Concepts TS convenience notation design, and was also acceptable to the primary concepts designers (hence the long list of coauthors). For the first time, besides the special case of generic lambdas, C++ will now let you write lots of generic functions without “template” or angle brackets, and that are concept-constrained and therefore much easier to use correctly than function templates have ever been before.
In the first part of my CppCon 2017 talk, I emphasized that C++ is serious about first-class compile-time programming. That is a general theme to current C++ evolution, and is particularly important for being able to make effective use of compile-time reflection, and for building on that further in the future for compile-time code generation such as my metaclasses proposal relies upon.
First-class compile-time programming in C++ has been building since we allowed simple one-liner constexpr functions in C++11, to constexpr functions with loops in C++14, to constexpr lambdas and “if constexpr” in C++17. This week, we have added still more as a coordinated set of additions to C++20:
We’re on track to making most “normal” C++ code available to run at compile time — and although C++20 won’t get quite all the way there, C++20 is a landmark release and a turning point where start to permanently leave behind the angle brackets and workarounds we’ve been using since the 1990s, with the near-complete birth of fully “natural” compile-time C++ code. Recall that we have already been adding support for user-defined types as template parameter types; soon (either before or after C++20’s feature freeze) we may be able to use strings as template arguments, and use containers like std::vector in compile-time code. Of course, there likely will be some limits; for example, supporting compile-time std::thread is possible, but less likely to be worth the effort.
Looking ahead to C++23 for a moment, where we expect still more of that plus (we hope) full static reflection in the standard, this marks a difficult-to-overstate landmark shift in C++ programming — not a course change, but really taking all the things that programmers have already been trying to do indirectly and giving it first-class natural support. The long-term results are likely to exceed our expectations in ways that we can’t fully anticipate yet. So fasten your seat belts, and stay tuned. C++ programming is likely to evolve more, and in better ways, in the upcoming 5 years than it already has in the past 20.
A number of other smaller changes were adopted as well.
Modules (Richard Smith; and Gabriel Dos Reis) for the first time had a unified design approved targeting C++20. Wording specification work will continue over the holidays, and we expect to consider modules for C++20 at our next meeting in February.
Executors: Thanks to progress between meetings and special meeting in September, we now are hopeful that an initial Executors design can make it for C++20. The feature was not merged at this meeting, but the design was approved for C++20 and we expect to consider adding the wording specification to C++20 at our next meeting.
Coroutines: We continued to make progress on coroutines. At this meeting, EWG again recommended merging the Coroutines TS (Gor Nishanov) into C++20, and this time EWG additionally explicitly included plans to incorporate features from the competing Core Coroutines proposal (Geoff Romer, James Dennett, Chandler Carruth). As in Rapperswil, the vote to merge the Coroutines TS into C++20 fell just short numerically and was not adopted for C++20 at this meeting. The proposers, and new collaborators from Facebook and other companies, will continue to work on improving consensus over the winter by addressing remaining concerns, including doing further work to merge features from Core Coroutines into the TS approach, such as an upcoming paper “A unifying design for Executors, Sender/Receiver, coroutines, parallel algorithms and networking” by Lewis Baker of Facebook which is expected to appear in the post-meeting mailing. We expect coroutines to be proposed again for C++20 at our February meeting in Kona with this additional information, and with the national bodies having more time to absorb the large amount of new information that was presented at this meeting.
Networking: This depends on Executors, and despite some discussion about decoupling the non-Executor parts, at this meeting we decided to target merging Networking into C++ for soon post-C++20 (i.e., targeting C++23). It also might depend on Coroutines, because some experts are still working through whether there is integration work to be done to merge Networking with Coroutines.
Reflection TS v1 (David Sankel) ISO ballot continues: The Reflection TS international comment ballot was already in progress during the meeting and will conclude next month. As I mentioned in my last trip report, note again that the TS’s current template metaprogramming-based syntax is just a placeholder; the feedback being requested is on the core “guts” of the design, and the committee already knows it intends to replace the surface syntax with a simpler programming model that uses ordinary compile-time code and not <>-style metaprogramming. In San Diego, we began looking at a “next-generation” reflection proposal P1240 (Andrew Sutton, Faisal Vali, Daveed Vandevoorde).
2D Graphics (Michael B. McLaughlin, Herb Sutter, Jason Zink, Guy Davidson, Michael Kazakov) sent back to SG13: The SG13 HMI (human-machine interface) study group was reopened with Roger Orr as chair and will be taking another look at next steps for the Graphics proposal in the coming months.
In addition to the two Incubator Study Groups I mentioned in my pre-trip report, we also formed two new domain-specific study groups:
SG19: Machine Learning (Michael Wong). We feel we can leverage C++’s strengths in generic programming, optimization and acceleration, as well as code portability, for the specific domain of Machine Learning. The aim of SG19 is to address and improve on C++’s ability to support fast iteration, better support for array, matrix, linear algebra, in memory passing of data for computation, scaling, and graphing, as well as optimization for graph programming.
SG20: Education (JC van Winkel). We feel we have an opportunity to improve the quality of C++ education, to help software developers correctly use our language and ecosystem to write correct, maintainable, and performing software. SG20 aims to create curriculum guidelines for various levels of expertise and application domains, and to stimulate WG21 paper writers to include advise on how to teach the new feature they are proposing to add to the standard.
Thank you to Michael and JC for volunteering as chairs!
Whew! Here is a cheat-sheet summary of our current reasonable expectations for some of the major pieces of work. Note that this is an estimate only, and progress can end up being different than expected.
And here is an updated snapshot of where we are on the schedule for C++20, which can always be found in paper P1000:
Thank you again to the approximately 180 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good winter… we look forward now to several interim telecons and potentially side meetings, and then our next regular WG21 meeting in February (Kona, HI, USA).
In one hour, our fall meeting will begin. I’ll still write a trip report at the end with the results of the meeting, but because this is an unusually (and historically) large meeting we’ve had to make a few adjustments.
This post is combined from a couple of administrative emails I sent to the committee over the past few weeks. Note that they’re written with that audience in mind, so they end with guidance about how to work effectively in the new subgroups, but I thought that others who follow C++ standardization would find them interesting and useful too.
As you may have noticed, we’ve been growing:
In the past we’ve had five main subgroups working during the week, but that doesn’t scale well to either the number of people (it’s not ideal to have ~170 in just five huge subgroups) or the number of papers (five subgroups will leave many papers unhandled). The following are some adjustments we’re making in order to scale organizationally.
Effective [October 19], we have formed two new Study Groups with the chairs shown below, both of which will meet in San Diego for three days each:
Thank you very much to JF and Bryce for making themselves available to serve as chairs!
We also have two expanded/reactivated Study Groups, both of which will meet in San Diego:
And we have a request for at least one new Study Group, though this will not be created until after San Diego:
So here’s an updated look at our current organization:
The subgroups with heavy outlines are the ones that, starting in San Diego, will meet for multiple full days during our face-to-face meetings. You’ll notice there are now eight (8) of those, and so starting in San Diego our new standard meeting space requirement will be 8 concurrent breakout rooms (was previously 6, with the 6th shared among SGs and usually lightly utilized). Here’s a summary of the breakout tracks in San Diego (and of course we’ll have plenary first thing Monday and on Saturday – a few subgroups may choose to also meet a little longer on Saturday after plenary, as usual, and that will be announced on Saturday):
(Insert your favorite “8-track” joke here, with de rigueur comment about C and C++ starting in the 1970s.)
I counted the #attendees (solid) and #papers (dashed) all the way back to my personal first meeting in July 1997. Here is the resulting graph.*
Please go look at the quaint 1997 papers page, when we completed C++98 standardization. Fun facts:
So our San Diego technical paper volume is within a close order of all the technical papers to produce C++98. And, as already noted, it’s more than Shakespeare’s lifetime published word count, even excluding the C++ working paper.
Also in 1997, two months before the first meeting shown in the above graph, there was a famous Q&A session at WWDC that included the following quote:
So we had to decide what are the fundamental directions we’re going in and what makes sense and what doesn’t. There were a bunch of things that didn’t, and microcosmically they might have made sense but macrocosmically they made no sense…
Focus is about saying no, and the result of that focus is going to be some really great products where the total is much greater than the sum of the parts.
— Some Guy, 1997 (and Bjarne Stroustrup, 2018, paraphrasing)
We are a standards committee, not a design team. A design team can assign work (because it has employees), can make decisions without democratic vote (because it has a hopefully-benevolent dictator), and can just refuse to listen to ideas. A standards committee isn’t like that: In WG21, we are volunteers and we always review as many papers as we can (of course we assume the author/champion is present etc., see SD-4). For us, “saying no” doesn’t mean ignoring by fiat, it means deciding as a group to decline to go in that direction after first listening to it.
The way I think of this mailing’s papers is in five “buckets”, illustrated here:
Yes, I can count. There’s a bucket 0 that’s not on the slide:
0. Thank you for your papers that used to be missing! In the past we’ve sometime had presentations and reflector mails without papers – aka “please write a paper,” and you did. Thank you for those.
1. Thank you for your bug-fix papers! We appreciate the many eyes to help our standard be better. We expect to take most of these (modulo agreeing on the right fix).
2. Thank you for your papers to improve an existing feature! We appreciate ways to remove limitations on our features (e.g., enable move-capture for lambdas). We expect to take some percentage of these (modulo agreeing on the right improvement).
3. Thank you for your new overlapping feature ideas! Sometimes there is a group of related narrower features where there is a lovable general feature struggling to hatch. We will try to merge-via-generalization N features into 1 general feature that can be orthogonal and composable with the rest of the language and library. Note that this frequently takes a number of meetings. Also, ideally it results in the ability to deprecate existing features by replacement-via-generalization (think how “using” subsumed “typedef”).
4. Thank you for still more new solo feature ideas! We will consider all of them, but for we expect to have a high bar for language proposals and require that they are composable with the rest of the language and clearly aligned with (a step in the direction of) where we want C++ to go in the next 10-30 years. And, over time, expect to see fewer of them, and to have them increasingly make existing features redundant (deprecate existing features by replacement-via-generalization, again).
Both #3’s merging and #4’s filtering procedures are aiming at the same goal: Producing a strong proposal that solves more than one problem.
Especially in #3 and #4, it’s unavoidable that the Incubator SGs will break hearts by saying “no.” So, please keep in mind the following tips.
When you are an Incubator SG participant, you will participate in polls that break hearts – so be kind, and especially watch for features that are #3’s (related to others and potentially generalizable) or look for ways to help them become #3’s (invite specific overlapping proposals that may not exist yet, to help complement and round out this proposal into something general), don’t just assume they’re #4’s (facing a difficult bar as a partly-fledged solo feature).
When you are an Incubator SG presenter, be prepared that not everyone may love your feature as much as you do, at least at first – but find ways to frame, and to evolve, your proposal to make it #3 instead of #4, especially by finding like-minded proposers of similar features that you can together turn into a #3 feature group and refine/complete/integrate together. Because it’ll be easier to succeed in #3 than in #4.
In general, we encourage all participants to consult:
Although we can’t read all the mailing, we can read these two items.
Thank you to everyone, especially to the new subgroup chairs and the existing officers and chairs and upcoming meeting hosts, who have worked very hard at short notice, especially over the past few weeks, to help organize for our current growth.
My Thursday talk is now online. Thanks to Mark Bashian and his wonderful team at Bash Films for posting the plenary sessions so quickly… it was great to see each keynote posted the following morning, and the rest of the CppCon 2018 videos will be posted in the next few weeks as usual.
Thanks again to everyone who came! It was a great conference, and we are already looking forward to next year’s CppCon in our new location in Denver, CO, USA.
I love C++. I also love safe code and not having to worry about dangling pointers and iterators and views. So I’ve been doing some work to make my life less conflicted: As long promised, the Lifetime profile 1.0 paper is now posted in the C++ Core Guidelines repo. It aims to detect common local cases of dangling pointers/iterators/string_views/spans/etc. in C++ code, at compile time, efficiently enough to run during normal compilation and in IDE tooltips. And, best of all (IMO), leveraging the rich information that’s already in typical modern C++ code, especially code that uses RAII and STL, with little or no annotation (e.g., see section 2.6).
For a quick summary, section 1.1 is a readable 3-page overview. Or, if you prefer watching a talk video, you can also see my CppCon 2015 talk starting at 29:06, where I first talked about this work; the approach is still the same. I’ll also be giving an update on this work next week at CppCon as one of the three major sections of my talk this year.
Many thanks to all of the people who contributed and gave feedback to help me flesh out this design over the past three years. I would like to especially thank Neil MacIntosh and Kyle Reed who did the bulk of the MSVC static analysis extension implementation work, and Matthias Gehre and Gábor Horváth who did the Clang-based implementation. Thank you! Those of you who’ll be at CppCon will see some of these folks on-stage showing their work in my talk, and be able to ask them questions at the conference.
… Did I say Clang? Yes, there’s now also a Clang-based implementation in addition to MSVC. Although I stress this work is still somewhat experimental and that both are partial implementations, both of them do already compile most of the examples in the paper and both already run efficiently enough to run during normal compilation (Clang) and in the IDE for live-squiggle diagnostics (MSVC) even though they have not been optimized yet. And, as you’d expect in 2018, the Clang-based implementation is available on Godbolt — in the paper, just search for “godbolt” to find over 30 links to live examples. Here are a few you might find interesting:
If you’re interested in preventing common cases of dangling pointers, iterators, string_views, spans, and more, efficiently at compile time with high quality diagnostics, check out the examples in the paper and play around with them on Godbolt.
If you find new examples that are correctly diagnosed that you think are particularly cool, feel free to distill them down to their essence (and sanitize them if they came from real code) and post them as new Godbolt links in the comments below — bonus points if you also briefly summarize what the problem is, and extra bonus points if they did come from real world code. I may add some of them to the paper, with attribution, and maybe even use one in next week’s talk.
In just 10 days, we’ll be at CppCon! I can hardly wait for Bjarne’s new opening keynote and the 100+ other sessions… we have a really great lineup of speakers again this year.
I’ll be giving a talk as well, and here’s the title and abstract for what I’ll be covering this year. I hope to see many of you in sunny Bellevue, WA, USA soon.
Perhaps the most important thing we can do for C++ at this point in its evolution is to make sure we preserve its core strengths while also directing its evolution in ways that make it simpler to use. That is my own opinion at least, and so this talk starts with a perspective question: What “is C++,” really? The language continues to evolve and change; as it does so, how can we be sure we’re picking C++ evolutionary improvements that not only don’t lose its “C++-ic” qualities, but make it a better C++ than ever?
At recent CppCons, I’ve spoken about several of my own personal C++ evolution efforts and experiments, and why I think they’re potentially important directions to explore for making C++ both more powerful and also simpler to use. The bulk of the talk is updates on two of these:
Lifetime and dangling. At CppCon 2015, Bjarne Stroustrup and I launched The C++ Core Guidelines in our plenary talks. In my part starting at 29:06, I gave an early look at my work on the Guidelines “Lifetime” profile, an approach for diagnosing many common cases of pointer/iterator dangling at compile time, with demos in an early MSVC-based prototype. For this year’s CppCon, I’ll cover what’s new, including:
I’ll summarize the highlights but focus on what’s new, so I recommend rewatching that talk video as a refresher for background for this year’s session.
Metaclasses. In my CppCon 2017 talk, I gave an early look at my “metaclasses” proposal to use compile-time reflection and compile-time generation to make authoring classes both more powerful and also simpler. In this case, “simpler” means not only eliminating a lot of tedious boilerplate, but also eliminating many common sources of errors and bugs. For this year, we’ll cover what’s new, including: