Trip report: Winter ISO C++ standards meeting (Kona)

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.

Notes:

  • Some of the links below are to papers that will not be published until the post-meeting mailing a few weeks from now, and so the links will start working at that time.
  • You can find a brief summary of ISO procedures here.

C++20 feature freeze

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.

Two more major features adopted for C++20: Modules and coroutines

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.

Other changes approved for C++20

A number of other smaller changes were adopted as well.

  • Extending structured bindings and reference capture of structured bindings (Nicolas Lesser) allow a name introduced as a structured binding to be used in additional ways that programmers would naturally expect to work, such as allowing them to be captured by reference in lambdas.
  • Allow initializing aggregates from a parenthesized list of values (Ville Voutilainen and Thomas Köppe) allows using () to initialize aggregates in addition to {}. See N4462 for an example of the kind of problems this fixes.
  • <=> != == (Barry Revzin) adds better language support for composability when writing <=> for types that can write a more efficient == than using the <=> operator alone. For example, vector<T> can short-circuit == comparison by first checking whether the two vectors have the same size; if they don’t, we know in constant time that they cannot be equal without comparing any of the elements. The previous guidance for such types was that in addition to <=> they should also overload == and !=, and that any types that compose such types have to know to do the same so as not to lose the optimization. With this change, we can more simply teach that for such types in addition to <=> they should also overload ==, full stop; there is no need to also overload !=, and no need for other types that use such a type to be especially careful so avoid losing the optimization .
  • Change span to use unsigned size, and add ssize() functions to get signed sizes (Jorg Brown and many others) makes std::span more convenient to use with existing STL types, while also allowing use of signed sizes and indexes via ssize() to get the benefits of signedness.
  • polymorphic_allocator (Pablo Halpern, Dietmar Kühl) allows pmr::memory_resource to be used wherever allocators can be used in the standard library.
  • Adopt vectorization policies from Parallelism TS2 (Alisdair Meredith, Pablo Halpern) further extends the parallel STL algorithms with vector execution policies that allow programs to exploit the parallelism of vector units available on modern CPUs.
  • A slew of broad papers restating the standard library in terms of our new C++20 language features of concepts and contracts that were already adopted at recent meetings. See P0788 and P1369 for a great overview of what this involves. This is part of the standard library’s intentional evolution toward replacing exceptions with contracts for preconditions (such as domain and range errors) in future C++.
  • Lots of smaller features and individual issues resolutions.

Other features targeting C++20 for the July meeting

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.

The shape of C++20 (modulo any additional features in July)

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:

  • modules
  • coroutines
  • concepts
  • contracts
  • <=> spaceship
  • “lots more constexpr”: broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip report)
  • ranges
  • calendars and time zones
  • span
  • and lots more

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.

Other progress and decisions

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.

18 thoughts on “Trip report: Winter ISO C++ standards meeting (Kona)

  1. I agree with Thomas McLeod that there is an issue with adoption of C++. But this was always like this. Most of my colleagues do not understand what exception handling is supposed to be used for. And this is available since C++98. Others fawn over new C++ versions but have yet to understand the exploitation of single-step-initialization (enabled by C++ exception handling).

  2. Lurking since 2008, I have never found occasion to comment, but just wanted to say: do you realize how useful your blog is? To a programmer, your blog is the most significant C++ news organ on the Internet. I hope that you never stop writing it.

  3. @Ole Erik Peistorpet

    “I’m thinking the type should be something like: ranges::difference_type< ranges::iterator_t >”

    The type of `ssize(c)` is actually

    std::common_type_t<std::ptrdiff_t, std::make_signed_t>

    so assuming the underlying range has a larger-than-ptrdiff_t size type, ssize will do the right thing.

  4. I’m a little concerned about ssize().

    Say you use it on some kind of range that wraps files. You probably want support for files bigger than 2 GB, so difference_type should be int64_t or equivalent. But what if the application is compiled as 32-bit? Using ptrdiff_t could lead to insidious bugs that only happen in rare corner cases.

    I’m thinking the type should be something like:

     ranges::difference_type< ranges::iterator_t<C> > 
  5. Hello Herb,
    Thank you for the summary. Unfortunately, the link for Coroutines is broken…
    Cheers!

  6. Looking over the feature list, this is obviously a major revision of the language. Some of these feature I personally have been following for a long time and I’m excited that the committee has finally accepted them into the standard. My concern is with commercial adoption. From what I’m seeing from my perch in the Boston metro area, the culture of C++ is still for the most part rooted in C and there is somewhat of an attitude of “if it ain’t broke, don’t fix it” with regard to compiler upgrades. There are major exception to this rule, I know, but I would like to see more discussion of what Modern C++ means so that it filters up to the Director and CTO level.

  7. @jmckesson: Thanks Reply

    By the way, why didn’t China participate in the ISO C++ Standards Conference? Because no Chinese company is interested? Or something else?

    Thank the members of ISO C++ Standards Committee for their efforts! C++ 20 has so many great updates! Modules and coroutines thank you! Let us all be very excited on the other side of the Pacific Ocean! When it comes to static reflection, why do we keep asking? Because in the future, when we face a large number of Internet of Things nodes, in the face of complex 3D graphics, in the face of machine vision and artificial intelligence, we need the separation of exponential-level algorithms and data, so language-level reflection support is very important. C++ has missed the prosperity of the web, but we should not miss the uncertain future.

  8. @Daveed: “I’m not aware of that being the case.”

    Admittedly, I said that before I realized that expansion statements were voted into C++20 (which was probably the biggest metaprogramming tool that `constexpr` didn’t have). And I didn’t realize this because… Herb forgot to mention it. That one’s kinda important ;)

    However, the delay of non-transient allocations to post-C++20 does mean that an important tool of *using* static reflection (building runtime reflection data) is not available. But so long as it’s there at the same time as static reflection gets voted in, it ought to be fine.

    @China feng: “What we expect is that we can traverse the reflected metadata during the run-time of the program, so that some dynamic data can run efficiently in the form of scripts, without repeating the compilation of the program, a large number of fatal binding!”

    It won’t work exactly like that. Static reflection is static: compile-time only. Now, you can use `consteval` code to generate some data based on static reflection properties, which your runtime code can then utilize. So you should be able to do script-based binding much more effectively than with existing tools.

    Structurally, it’ll be similar to existing metaprogramming-based tools for binding scripting languages to C++. Of course, it’ll be much easier to maintain, since it won’t be template metaprogramming-based.

  9. [quote]
    Static reflection, with a `constexpr`-based interface requires more `constexpr` stuff than C++20 will get.
    [/quote]

    I’m not aware of that being the case. In fact, that was a specific goal of the constexpr extension work: Front load C++20 so that SG7 can focus on the design of the reflection and metaprogramming facilities themselves. E.g., P1240 relies only on C++20 facilities for the constexpr part.

    That doesn’t mean that we won’t add more facilities in that area (and they might very well end up being useful for reflection): I’m actually working on one such extension.

  10. Thank! Thank! Reflection TS v1 (David Sankel, Axel Naumann) completed? Has this been partially incorporated into the C++ 20 standard? What we expect is that we can traverse the reflected metadata during the run-time of the program, so that some dynamic data can run efficiently in the form of scripts, without repeating the compilation of the program, a large number of fatal binding!

  11. “Want to know if reflection can enter the C++ 20 standard?” That was never really on the table for the C++20 time frame. Static reflection, with a `constexpr`-based interface requires more `constexpr` stuff than C++20 will get. Plus, there is still a lot of design discussion to go with that.

  12. As noted in the post, many of the papers (explicitly the ones in that section) will be part of the post-meeting mailing, so the links don’t work yet.

  13. Herb, the links at the Coroutines section are throwing an 404.
    Could you please check that issue or, if you have the time, send a copy of the papers to my e-mail? I’m very interested in reading them!

    Thank you!

Comments are closed.