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.

Notes:

• Some of the links below are to papers that will not be published until the post-meeting mailing at the end of this month, and so the links will become public at that time.
• For more details, see also the Reddit trip report.
• You can find a brief summary of ISO procedures here.

Prelude: Focus

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:

• By word count, it exceeded Shakespeare’s complete published works.
• By paper count, it exceeded the previous pre-meeting papers record by about 65%, and started to approach the total number of technical papers to produce the first C++ standard (total of pre-meeting mailings from 1990-1997).

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:

• About a year ago, we created the Direction Group (Bjarne Stroustrup, Daveed Vandevoorde, Michael Wong, Howard Hinnant, Roger Orr, and the recently retired Beman Dawes) which has created and maintains an advisory document Direction for ISO C++ (P0939).
• In 2018, Pearson Education made free electronic copies of The Design and Evolution of C++ (Bjarne Stroustrup) available to all committee members. Not only does this help ensure that the newer people have access to this expected-to-be-read foundational work, which continues to be very current, but also having it in machine-readable and -searchable form makes it much easier to reference and quote from in our own papers.
• At this meeting, we let EWG and LEWG continue to focus on near-term papers, and created SG17 (EWG Incubator, JF Bastien) and SG18 LEWG Incubator (Bryce Adelstein Lelbach) to help review and improve the papers that EWG and LEWG could not handle, to improve them and to prune them before they reach the main subgroup. Thank you to JF and Bryce for being willing to chair these new groups!

Two major features adopted for C++20: Ranges, and Concepts convenience notation

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.

More constexpr adopted for C++20: Ongoing concerted push toward general compile-time programming

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:

• “consteval” immediate functions (Richard Smith, Andrew Sutton, Daveed Vandevoorde), which came in part from Andrew’s and my metaclasses work, allow writing functions that are guaranteed to run at compile time. This is essential for the kind of code generation that metaclasses rely on, and it’s great to see this now adopted as part of C++20!
• constexpr union (Louis Dionne, Daveed Vandevoorde) lets you change the active member of a union during compile-time code.
• constexpr try and catch (Louis Dionne) lets you write try/catch in constexpr code. However, note that it doesn’t actually let you throw exceptions at compile time.
• constexpr dynamic_cast and typeid (Peter Dimov, Vassil Vassilev) lets you write dynamic_cast and typeid in compile-time expressions. Note that virtual function calls are already allowed in constant expressions (that was approved at our previous meeting).
• std::is_constant_evaluated (also by Richard Smith, Andrew Sutton, Daveed Vandevoorde) lets you write conditional code that lets you write part of a function using code that is guaranteed to be executed at compile-time. Another way to think of it is that it’s similar in spirit to “if constexpr” except that it lets you combine “if constexpr” with an “else normal-if.”
• constexpr std::pointer_traits (Louis Dionne) is an essential ingredient for enabling compile-time reflection and especially compile-time std::vector. (Compile-time std::vector will also need compile-time new, still under development.)
• Miscellaneous constexpr library bits (Antony Polukhin) added still more constexpr within the standard library, which means making even more of the standard library available to compile-time code.

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.

Other changes approved for C++20

A number of other smaller changes were adopted as well.

• Revising the C++ memory model (Hans-J. Boehm, Olivier Giroux, Viktor Vafeiades, et al.) makes several updates for weaker architectures including better support for GPU memory. Weaken release sequences (Hans-J. Boehm, Olivier Giroux, Viktor Vafeiades), a related paper forked from the main one, was also approved.
• Today’s return-type-requirements are insufficient (Walter E. Brown, Casey Carter) tightens up Concept-constrained return type deduction.
• Access control in contract conditions (J. Daniel Garcia, Ville Voutilainen) lets public functions’ preconditions and postconditions also access private members.
• Signed integers are two’s complement (JF Bastien) is the result of a courtroom drama in both WG21 (C++) and WG14 (C). After intense prosecutorial cross-examination, the witness finally admitted in both courts that, yes, all known modern computers are two’s complement machines, and, no, we don’t really care about using C++ (or C) on the ones that aren’t. The C standard is likely to adopt the same change.
• char8_t: A type for UTF-8 characters and strings (Tom Honermann) is another step toward broad Unicode support.
• Nested inline namespaces (Alisdair Meredith) extends the new C++20 convenient nested namespace declaration syntax also for inline namespaces.
• Missing feature test macros (John Spicer) adds support for missing macros that let code test for the presence of three features: destroying delete, three-way comparison (spaceship), and conditional explicit.
• Several cleanup updates to std::optional, std::variant, std::function.
• visit<R> (Michael Park, Agustín Bergé) allows specifying the return type when visiting variants.
• reference_wrapper for incomplete types (Tomasz Kamiński, Stephan T. Lavavej, Alisdair Meredith) lets the wrapper work for forward-declared and abstract types.
• assume_aligned (Timur Doumler, Chandler Carruth) enables portable code to express an alignment optimization hint to the compiler.
• Smart pointer creation with default initialization (Glen Fernandes, Peter Dimov) adds allocate_shared_default_init, make_shared_default_init, and make_unique_default_init to perform default initialization.
• Should span be Regular? (Tony Van Eerd) removes the comparison operators from std::span.
• Heterogeneous lookup for unordered containers (Mateusz Pusz) enables indexing without creating a temporary key object.
• Simplified partial function application (Tomasz Kamiński) adds bind_front to the library.
• Lots of smaller features and individual issues resolutions.

Other progress and decisions

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.

Upcoming new work: Machine learning and education

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!

What’s next

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).