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.


  • 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:

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.

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

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.

New Study Groups: EWG Incubator and LEWG Incubator

As you may have noticed, we’ve been growing:

  • Record #people: 173 unique names known so far for San Diego.
  • Record #papers: 274 in pre-San Diego.

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:

  • SG17 “EWG Incubator SG” (JF Bastien)
  • SG18 “LEWG Incubator SG” (Bryce Adelstein Lelbach)

Thank you very much to JF and Bryce for making themselves available to serve as chairs!


  • The “(L)EWG Incubator” SGs are not additional (L)EWG groups, they are (like all SGs) a pipeline stage in front of EWG and LEWG respectively.
  • As advertised in our agenda, in San Diego (L)EWG will again prioritize C++20-targetable material first, and the Incubator SGs’ primary agendas will be to schedule those papers that are not likely to fit in the main (L)EWG groups. The chairs are coordinating their agendas. Please consult the daily agendas that will be maintained on the wiki to see what topics are scheduled for each session, so that you don’t miss your favorite topic.
  • Although SGs typically forward work to (L)EWG, they can as needed forward work to each other too if they believe the proposal needs domain expert input from that SG before entering (L)EWG. Papers that are primarily about a topic that is owned by an active topic-specific SG should still go to that SG; for example, all other SGs normally redirect any stray concurrency-related papers they receive to SG1 instead.
  • Like most SGs, we should expect the Incubator SGs will forward only a subset of what they receive to (L)EWG, sometimes after first asking for significant changes. As with all SGs, any papers that these SGs refine and forward need to pass through (L)EWG as usual, including to meet the IS ship deadlines described in P1000. As with all SGs[*], SG17 and SG18 never “pre-bless” proposals; if SG17/18 approves forwarding a proposal to (L)EWG, that just means it is ready to have an initial presentation in (L)EWG and begin its journey in those groups, not that it has any default positive standing in (L)EWG. There should never be an expectation of “well the SG blessed it, if we’d wanted to comment we should have been in the SG.”
    • [*] except for SG1 uniquely; proposals coming from SG1 do often have some advanced standing and trust because of SG1’s demonstrated expertise and history, but even SG1’s proposals get looked at by (L)EWG first and don’t skip (L)EWG entirely
  • The quantity of work that we process into the standard is still gated by CWG and LWG bandwidth. Therefore a major function of the Incubator SGs is act as a selection pipeline stage to turn higher input volume into higher average quality, and avoid the status quo default of papers backing up in front of EWG/LEWG/CWG/LWG.

We also have two expanded/reactivated Study Groups, both of which will meet in San Diego:

  • SG12 “UB, Undefined/Unspecifed Behavior” (Gabriel Dos Reis) is now regularly meeting for ~3 days, co-located again with our sister WG23 (Vulnerabilities) in San Diego. – So San Diego is again a combined WG21/WG23 meeting, not just WG21.
  • SG13 “HMI, I/O” (Roger Orr) is now reactivated to handle the Graphics proposal that does not currently have consensus to proceed in LEWG but has a critical mass of people actively interested in working on it, so it makes sense to reactivate the SG. Also, that proposal is actually a group of some 5-6 sub-proposals, so it will be up to SG13 to decide whether to incubate them as a group or individually, and then feed them to appropriate other subgroups for consideration when ready. Thank you to Roger for being willing to chair the group!

And we have a request for at least one new Study Group, though this will not be created until after San Diego:

  • Several companies have approached me to actively pursue work in Machine Learning. No concrete announcement yet, but I’m penciling in an ‘SG19 (chair tbd)’ for that.

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

Perspective: Our history and trajectory

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:

  • The highest paper number was N1148. So we had 1148 papers in the entire 8-year cycle to produce C++98.
  • Pre- and post-meeting mailings were typically of a similar size. So we had ~600 pre-meeting papers in the entire 8-year cycle to produce C++98.
  • Many of those were issues lists, a higher proportion than today. And the technical papers were typically shorter than today’s.

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)

What does “focus means saying no” mean to WG21?

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.

What you can do (message to new subgroup participants)

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:

  • P0939, the Direction Group’s suggestions – people are not expected to necessarily agree with every part but we should be open to the well-informed advice therein.
  • D&E, which is available for free to committee members – contact Bjarne to get a copy.

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:

  • godbolt.org/z/szJjnH A simple starter dangling raw pointer example.
  • godbolt.org/z/_midIP This one’s simple but fun… quick, how is the pointer use on line 11 invalidated by the following line, line 12?
  • godbolt.org/z/dymV_C From C++17: A dangling string_view, which is important because it turns out to be easy to convert a std::string to a string_view, so that dangling is almost the default behavior.
  • godbolt.org/z/eqCRLx From the very latest bleeding edge: A dangling filter_view from the Ranges TS that we’re about to see if we can merge into the standard in time for C++20. Those are non-owning indirections, so they can dangle too.
  • godbolt.org/z/iq5Qja From C++98 with a dash of C++11: You know how using auto to deduce a vector<bool> subscript [] operator actually captures a vector<bool>::reference proxy, which can dangle after a push_back or reserve? If you didn’t: Sorry to be the bearer of sad tidings, but here’s some good news about that example.
  • godbolt.org/z/UE-Mb0 This short example can take a few minutes to grok… take a cup of coffee to understand who owns what and points where, and why the pointers are dangling (or not), and what the compiler is understanding about our code in order to be able to tell us about the problems accurately.

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.


Thoughts on a more powerful and simpler C++ (5 of N)

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:

  • use-after-move diagnoses
  • better support for the standard library out of the box without annotation
  • more complete implementations in two compilers: in MSVC as a static analysis extension, and in a Clang-based implementation that is efficient enough to run during normal compilation
  • the complete 1.0 Lifetime specification being released on the Guidelines’ GitHub repo this month

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:

  • an update on the Clang-based implementation, which now supports more use cases including function parameter lists
  • new examples, including from domains like concurrency
  • an updated P0707 paper, with more links to working examples live on Godbolt, being posted in the next few weeks for the pre-San Diego committee mailing


On Saturday June 9, the ISO C++ committee completed its summer meeting in beautiful Rapperswil, Switzerland, hosted with thanks by HSR Rapperswil, Zühlke, Netcetera, Bbv, SNV, Crealogix, Meeting C++, and BMW Car IT GmbH. We had some 140 people at the meeting, representing 11 national bodies. As usual, we met for six days Monday through Saturday, this time including all evenings.

Per our C++20 schedule, this was the second-last meeting for merging major language features into C++20. So we gave priority to the major 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. We expect to get to these soon once C++20 is well in hand.

Top news: Contracts adopted for C++20

Contracts (Gabriel Dos Reis, J. Daniel Garcia, John Lakos, Alisdair Meredith, Nathan Myers, Bjarne Stroustrup) was formally adopted for C++20.

Contracts allow preconditions, postconditions, and assertions to be expressed in code using a uniform syntax, with options to have different contract levels, custom violation handlers, and more.

Here are a few quick examples to get the flavor. Let’s start with perhaps the most familiar contract, assert:

void f() {
    int x = g();
    int y = h();
    [[assert: x+y > 0]]

“But wait,” someone might say, “C’s assert macro was good enough for my grandpappy, so shouldn’t it be good enough for me?” Never fear, you can still assert(x), but if you respell it as [[assert:x]] you get some benefits. For example:

  • You’re not relying on a macro (unlike C assert). Yes, this matters, because macros are outside the language and routinely cause problems when using language features. For example, this was demonstrated again just a few days ago on Twitter by Nico Josuttis (HT: Alisdair Meredith), who pointed out that assert(c==std::complex<float>{0,0}) does not compile; the reason is because macros don’t understand language commas, but [[assert: c==std::complex<float>{0,0}]] works just fine without any surprises.
  • You get to install your own violation handler and ship a release build with the option of turning on enforcement at run time.
  • You get to express audit to distinguish expensive checks to be run only when explicitly requested.
  • You get to express axiom contracts that are intended to never generate run-time code but are available to static analysis tools.
  • Finally, you will likely get better performance, because contracts should enable compilers to perform more optimizations, more easily, than expressing them using assertions.

But there’s more, because of course contracts are not just about assertions. They also include expects preconditions and ensures postconditions, which are part of the function declaration and so are visible at call sites:

double sqrt(double x) [[expects: x >= 0]];

void sort(vector<emp>& v) [[ensures audit: is_sorted(v)]];
    // could be expensive, check only when audit is requested

In addition to similar benefits as for assert, expects preconditions in particular deliver some enforcement benefits that are very desirable and difficult or impossible to get by hand:

  • Preconditions are usually enforced at the call site, which is what we want most of the time because a precondition violation always means a programming bug in the calling code.
  • But preconditions can also be enforced in the callee, which can sometimes be necessary for pragmatic reasons, such as when the function is invoked through an opaque function pointer.
  • Preconditions and postconditions that are known at the call site also give the optimizer more information to potentially make your code fast.

As a cheeky aside, if you noticed that I mentioned optimization several times, it’s for the usual reason: The simplest way to get C++ programmers to want a feature is to show that it can make their code faster, even if performance isn’t the only motivation or benefit.

Why contracts are a big deal, and related Rapperswil progress

In my opinion, contracts is the most impactful feature of C++20 so far, and arguably the most impactful feature we have added to C++ since C++11. That statement might surprise you, so let me elaborate why I think so.

Having first-class contracts support it is the first major “step 1” of reforming error handling in C++ and applying 30 years’ worth of learnings.

Step 2 is to (gradually) migrate std:: standard library precondition violations in particular from exceptions (or error codes) to contracts. The programming world now broadly recognizes that programming bugs (e.g., out-of-bounds access, null dereference, and in general all pre/post/assert-condition violations) cause a corrupted state that cannot be recovered from programmatically, and so they should never be reported to the calling code as exceptions or error codes that code could somehow handle. Over the past three meetings (Albuquerque through Rapperswil), the Library Evolution Working Group (LEWG) voted unanimously to pursue P0788R2 (Walter Brown) and relatedly in Rapperswil voted unanimously to pursue section 4.2 of P0709 (my paper), which includes pursuing a path of gradually migrating all standard library preconditions from exceptions toward contracts. (Note that in the near term, the idea is for implementations to be allowed, but not required, to use contracts. We are bringing the community forward gently here.)

Why is step 2 so important? Because it’s not just window dressing: Gradually switching precondition violations from exceptions to contracts promises to eventually remove a majority of all exceptions thrown by the standard library(!). This principle applies across programming languages; for examples, in Java and .NET some 90% of all exceptions are thrown for precondition violations (e.g., ArgumentNullException). Being able to eliminate a majority of all exceptions, which eventually enables many more functions to be noexcept, is a huge improvement for both correctness and performance:

  • Correctness: It eliminates a majority of the invisible control flow paths in our code. For example, over 20 years ago I wrote GotW #20 [Sutter 1997] that shows how today a 4-line function has 3 normal execution paths and 20 invisible exceptional execution paths; if we can eliminate a majority of the functions that can throw, we immediately remove a majority of the invisible possible execution paths in functions like this one, in all calling code.
  • Performance: More noexcept enables more optimization and faster code. (You knew that was coming, right?)

Once you change all preconditions (and postconditions and assertions) from exceptions to contracts, eliminating some of the largest categories of exceptions, one specific kind of exception dominates all others: bad_alloc. Which brings us to step 3…

Step 3 is to consider handling heap exhaustion (out-of-memory, OOM) differently from other errors. If in addition to not throwing on precondition violations we also do not throw on OOM, the vast majority of all C++ standard library functions can be noexcept. — Needless to say, this would be a huge change where we need to tread carefully and measure impact and high-fidelity compatibility in major real code bases, and we don’t want people to panic about it or think we’ve lost our minds: We are serious about bringing code forward gently after validating good adoptability and low impact long before this gets near an actual standard.

Nevertheless, we are also serious about improving this, and the fundamental change is simple and already fully supported in C++ today: In Rapperswil, LEWG also voted unanimously to pursue section 4.3 of P0709 (my paper) which proposes pursuing a path of gradually migrating all OOM from bad_alloc to new(nothrow)-like mechanisms. The initial contemplated step, definitely not for C++20, would be to change the default new_handler from throwing bad_alloc to calling terminate. That might sound like a big change, but it’s not, it’s already fully supported in C++ today because you can already change the new_handler to terminate today with a single line of code (std::set_new_handler([]{terminate();});), and this would just be changing the default and existing code that wants to keep the current behavior could still write simply the reverse single line of code (std::set_new_handler([]{throw std::bad_alloc();});) to get exactly the current behavior.

To repeat, this is a feature that will want a clear high-fidelity zero-breakage migration path, and we’re treating that compatibility seriously, even as we are also treating solving this problem seriously to modernize C++ error handling and move toward a mostly-noexcept world.

You can find a more detailed writeup in my new proposal P0709, particularly sections 1.1, 4.2, and 4.3. Again, P0709 is not for C++20, it is to illustrate a direction and potential path. The other parts of P0709 have not yet been reviewed by the full committee, so for now they should not be treated as anything more than a proposal, subject to much discussion and feedback over the coming several years.

Other new features approved for C++20

We adopted several other new features into the draft standard.

Feature test macros (Ville Voutilainen, Jonathan Wakely). This enables code to portably test whether a certain new C++ feature exists. “Why would I do that?” someone might ask. The primary and biggest benefit is they help your team to start to adopt new C++ features even before all your compilers support them; just write

#if /*new feature is present*/ // temporary
    nice clean modern code!    // <-- keep this long-term
#else                          // temporary
    do it the old way          // temporary
#endif                         // temporary

and eventually drop the #if test and the whole #else block as soon as all your compilers are up to date. This is so much better than today, where one of two things happens: (1) Teams often wait until all their compilers support a given new C++ feature before they start to use it, which slows down adopting the new features and getting their benefits at least on the compilers that do support it. Or, (2) teams roll their own nonstandard nonportable compiler-specific “approximate” feature tests (e.g., write their own macro for “I know this feature is available on version ## of MSVC and version ## of GCC” by hand).

We all agree we don’t like macros. However, we don’t yet have replacements for all uses of macros, including this one, and these standard macros are better than rolling your own nonstandard ones or, more likely, just not using new C++ features at all for a longer time.

Some experts still disagree, and we respect their views, but in my view these feature test macros are an important and pragmatic help to improve the speed of adoption of new standard C++ features.

Standard library concepts (Casey Carter, Eric Niebler). This is the first part of the Ranges TS to be merged into C++20 at an upcoming meeting, and contains the core concepts from the Ranges TS. It is also the first appearance of the concepts language feature in the standard library. Expect more to come for C++20 (see Ranges, below).

Class Types in Non-Type Template Parameters (Jeff Snyder, Louis Dionne). Yes, you can now have types other than int and char as non-type template parameters. For example, in addition to template<int Size>, you can now have things like template<fixed_string S> for a suitably defined class type. It turns out that this builds on the <=> spaceship comparison operator; and if you’re wondering why, it’s because we know the semantics of a defaulted <=> comparison, which is essential because the compiler has to perform comparisons to determine whether two template instantiations are the same.

Note: I did not have this benefit in mind at all when I proposed <=>. I think this is a great example where, when you let programmers express intent explicitly as with <=>, and provide useful defaults, you are inherently adding more reliable information to the source code and will reap additional benefits because you can now build on knowledge of that clear programmer intent.

explicit(bool) (Barry Revzin). This is conditional explicit, along the same lines as conditional noexcept. It lets library writers write explicit at a finer granularity, to turn off conversions where possible and feasible, without having to write two functions all the time.

Bit-casting object representations (JF Bastien). Header <bit> now lets you bit_cast. “But wait,” someone may be thinking, “don’t we already have reinterpret_cast?” Yes we do, and this is still a reinterpreting operation, but bit_cast has less unsafety and some additional flexibility: it ensures the sizes of the From and To types match, guarantees that they are both actually trivially copyable, and as a bonus makes the operation constexpr wherever possible.

Speaking of constexpr bit_cast, here are some more items in the “constexpr all the things!” department:

Other progress and decisions

Reflection TS is feature-complete: The Reflection TS was declared feature-complete and is being sent out for its main comment ballot over the summer. 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.

Parallelism TS2 is done: The second Parallelism TS is done! We completed ballot comment resolution, and approved the final TS for publication. This TS includes more execution policies, an exception_list type to communicate multiple parallel exceptions, and more parallel algorithms including wavefront, reductions, inductions, parallel for, and more. It also includes task_block support to enable writing custom parallel algorithms.

Graphics (io2d) is deferred: Many thanks to Michael McLaughlin especially, and to Guy Davidson, Michael Kazakov, and David Ludwig for their assistance with the design, specification, and implementation of this cross-platform library. This is a project that has been worked on for several years, and for the past two years has been primarily responding to committee tweak requests; unfortunately, although the committee requested a series of updates to the proposal that have been applied, at this meeting the committee decided that it does not have interest to pursue further work on graphics in any form at this time after all. However, the io2d project will continue, and be available on package managers (Conan, vcpkg), and we expect a renewed proposal in the medium term; in the meantime, watch Guy Davidson’s blog for news and updates.

Also, LEWG adopted P0921r2 as a statement of their direction for future C++ standard library evolution compatibility guarantees.

Updates on other major proposals

Here are other major items in progress. You’ll notice that the first six (6!) of them mention expectations for our next meeting this November in San Diego. Not all of those items will make C++20 in San Diego, but people are going to try. It’s not surprising that San Diego is going to be a busy meeting, though; that was expected, because it’s the last meeting to merge major features into C++20, and deadlines are famously motivational. — Just do not expect all of the following to make C++20, and I’m listing them in rough order starting with the most likely to make it in.

(very likely for C++20) Ranges: In my previous trip report I mentioned that the core concepts from the Ranges TS were expected to make C++20, but the rest of the Ranges TS would be “C++20 or C++23.” Since then we have made faster than expected progress, and it now looks like Ranges is “likely” to make C++20 in the next meeting or two. For those interested in details, in addition to all of the Ranges TS, also paper P0789 on Range Adaptors and Utilities have now progressed to detailed wording review and are targeting C++20. In sum, to quote Eric Niebler: “If you liked the Ranges TS, you’ll love C++20.”

(likely for C++20) Concepts: “convenience” notation for constrained templates: We already added the concepts core feature to C++20, and at this meeting we had further discussions on adding a convenience syntax to write constrained templates without resorting to the low-level “requires” keyword. The two major active proposals that received discussion were from Bjarne Stroustrup and from me. The good news is that the Evolution Working Group (EWG) liked both, which means that for the first time we have a proposal based on the TS syntax (Bjarne’s preference) that could get consensus to be approved!

The key people are continuing to work to come up with a merged proposal that might be adoptable for C++20 in November in San Diego, and I’m pleased to report that as of this post-meeting mailing we for the first time have a unified proposal that lists most of the previous authors of papers in this area as coauthors, you can find it here: P1141R0: “Yet another approach for constrained declarations.” I’m guardedly optimistic that we may have a winner here; we’ll know in San Diego. (I sometimes delay my trip report until the post-meeting mailing is available so that everyone can see the latest papers, and knowing that this new paper was coming was one reason I delayed this report.)

(maybe for C++20) Coroutines: EWG considered an alternative, then decided to go forward with the TS approach. That came up for full committee vote but fell just short and was not adopted for C++20; the proposers will continue to work on improving consensus over the summer by addressing remaining concerns and we expect coroutines to be proposed again for C++20 at our November meeting in San Diego.

Modules: For the first time, the committee saw a merged approach that both major proposers said satisfies their requirements; that announcement was met by applause in the room. The merged proposal aims to combine the “best of” the Modules TS and the Atom alternative proposal, and that direction was approved by EWG. EWG did not approve the poll to incorporate a subset of it into C++20 at this meeting; it is not yet clear whether part of the proposal can make C++20 but we are going to have an extra two-day meeting in September to help make progress and we expect it to be proposed again for C++20 at our November meeting in San Diego.

Executors: This is still not expected to be part of C++20, but key people have not given up and are trying to make it happen, and one never can tell. We are going to hold an extra two-day meeting in September to help make progress on Executors, and expect to have a lively discussion about options to merge all or parts of it into C++20 in November in San Diego.

Networking: This is pretty much ready except that it depends on Executors. Soon after Executors are ready for C++20, Networking is ready to slide in right behind it.

Clearly San Diego is going to be a busy meeting. But before then we have two extra design meetings on modules and executors to help improve their chances of progress; those will be co-located with CppCon in September, to take place near the CppCon site on the days just before the conference begins. On top of that, there will also be an extra library wording issues meeting in the Chicago area in August… all in all, it’ll be a full summer and fall before we even get to San Diego.

Additionally, SG12 had productive discussions about undefined behavior (including with participation from our sister ISO working group WG23, Programming Language Vulnerabilities), and SG15 had a second exploratory evening session focusing on package managers for C++.

What’s next

Here is a cheat-sheet summary of our current expectations for some of the major pieces of work. Note that, as always, this is an estimate only. The bolded parts are the major changes from last time, including that Ranges as a whole is looking very likely for C++20.


And here is an updated snapshot of where we are on the timeline for C++20 and the TSes that are completed, in flight, or expected to begin:


Thank you again to the approximately 140 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good spring… we look forward now to our next “extra” meetings in September (Bellevue, WA, USA) and the next regular WG21 meeting in November (San Diego, CA, USA).

[Edited to add C++20 schedule at end]

On Saturday March 17, the ISO C++ committee completed its winter meeting in Jacksonville, Florida, USA, hosted with thanks by the Standard C++ Foundation and Perennial. We had some 140 people at the meeting, representing 8 national bodies. As usual, we met for six days Monday through Saturday, including all evenings.

A special highlight was on Thursday evening (the only non-officially-working evening) when Bjarne Stroustrup personally hosted the entire committee for a celebratory dinner to share the 2018 Charles Stark Draper Prize, the U.S.’s top engineering honor, which this year was awarded for a programming language for only the second time in its history. Although the prize was awarded to Bjarne personally, he made it clear that he considered this an award for the whole C++ community, without whom C++ would never have been successful, and so he hosted the dinner for the committee as a representative proxy for the entire worldwide C++ community. — So to all C++ programmers and contributors who are reading this: Thank you, from Bjarne and from us, for your support, and consider yourselves part of this year’s Draper Prize.

The following are some highlights of what we achieved this week. You can find a brief summary of ISO procedures here. The main things to note are:

  • “IS” means “international standard.” In our case, it’s the core C++ standard itself. Think of this as “trunk.”
  • “TS” means “technical specification,” a document separate from the main standard where we can gain experience with new features before putting them into the IS. We have several of these, summarized on the status page. Think of these as “beta branches.”

Leading up to this meeting

As I reported in my previous trip report for the fall meeting (Albuquerque 2017), last time we almost completed addressing the comments received from national bodies in the Modules comment ballot that ran last summer. The rest were addressed in a series of teleconferences between meetings, and the Modules TS was finalized and shipped to ISO at the end of January.

One of the highlights in the pre-meeting mailing was “Direction for ISO C++” (Beman Dawes, Howard Hinnant, Bjarne Stroustrup, Daveed Vandevoorde, Michael Wong). Although non-binding, it’s the first set of recommendations from our recently created advisory Direction Group, a small subgroup of respected long-time participants that currently consists of those paper authors and is chaired this year by Bjarne Stroustrup.

Features adopted for C++20

We adopted several new features into the draft standard.

[[no_unique_address]] (Richard Smith). You know the empty base optimization (EBO)? If you do, can you remember the (probably many) times you’ve artificially made another class a base of your class, instead of just a data member, just so you could get EBO? And, every time that happened, you wished C++ had the empty member optimization (let’s call it “EMO”)? In C++20, it does, and you opt in via [[no_unique_address]]. Here’s an example from the paper:

template<typename Key, typename Value,
         typename Hash, typename Pred, typename Allocator>
class hash_map {
  [[no_unique_address]] Hash hasher;         // EMOji
  [[no_unique_address]] Pred pred;           // EMOji
  [[no_unique_address]] Allocator alloc;     // EMOji
  Bucket *buckets;
  // ...
  // ...

[[likely]] and [[unlikely]] (Clay Trychta). (The link is to R2 of the paper, which contains more description. The R4 version is the one that was adopted.) Many compilers already allow you to “hint” whether a branch is likely or unlikely to be true, which can help optimizations. This standardizes that. Here’s an example from the paper:

if (foo()) [[unlikely]] return false;
if (bar()) [[unlikely]] return false;

Major disclaimer: This feature comes with the same warning label as the existing compiler extensions, which is “measure, measure, measure!” Compilers already know which branches are likely, usually better than you do (especially with profile-guided optimization, aka PGO). A major reason to use this feature is not actually to optimize (though it can help if you don’t have PGO), but to control which path gets optimized for other reasons. For example, for some code it is essential to make the uncommon path faster so that it is faster when you do hit it — and in such cases you would actually use this attribute in the inverted sense, so please also write a comment nearby to document that intent otherwise some hapless reader (more than likely your future self) will be temporarily confused.

Extending <chrono> to calendars and time zones (Howard Hinnant, Tomasz Kamiński). This is a much-loved (and huger-than-you-think) library addition that will help a lot of users, and really exercises modern C++ features like user-defined literals.

span: Bounds-safe views for sequences of objects (Neil MacIntosh, Stephan T. Lavavej). This one comes directly from the C++ Core Guidelines’ Guideline Support Library (GSL), and is intended to be a replacement especially for unsafe C-style (pointer,length) parameter pairs. We expect to be used pervasively as a vocabulary type for function parameters in particular.

Cleanup adopted for C++20

We also made some improvements to existing features.

“Down with typename!” (Nina Ranns, Daveed Vandevoorde). Are you tired of writing typename redundantly in places where the compiler should know only a type was possible? So were the proposal authors. Now typename is required in fewer places.

Lambda capture initializers can now expand variadic parameter packs (Barry Revzin). An example, taken from the paper:

template<class F, class... Args>
auto delay_invoke(F f, Args... args) {
    return [f=std::move(f), ...args=std::move(args)]() -> decltype(auto) {
        return std::invoke(f, args...);

The now-allowed expansion is the one in the third line.

Consistent begin/end for range-for (Ville Voutilainen). The range-based for loop is already customizable, and can handle ranges that have both member rng.begin()/rng.end() functions or ones that have non-member begin(rng)/end(rng) functions. But what if it relies on the non-member functions, but happens to also have one member named either begin or end (such as, say, end in ios_base)? That’s now legal, we ignore the one-off member and use the non-member pair. Here’s an example from the paper that is not legal in C++17 but now works in C++20:

struct X : std::stringstream { /*...*/ };

std::istream_iterator<char> begin(X& x)
  { return std::istream_iterator<char>(x); }

std::istream_iterator<char> end(X& x)
  { return std::istream_iterator<char>(); }

int main() {
    X x;
    for (auto&& i : x) {   // works in C++20
      // ...

Interesting tidbit: This is one of those “new functionality” features created by removing wording in the standard, namely removing a restriction. The entire wording change was to change “either (or both) finds” to “both find” in one place.

Structured bindings can access accessible members (Timur Doumler). In C++17, you could use structured bindings to bind to class members as long as they were public. But what if you’re inside a member or friend of the class? Shouldn’t you be able to use structured bindings on members, which are visible (i.e., accessible) to you even if they aren’t public to everyone, just like we can do any other normal thing with those members? In C++17 that didn’t work, but it was an oversight and now we can do that:

class X {
    int i;
    int j;
    friend void f();

void f() {
    X x;
    auto [myi, myj] = x;   // now ok

We also adopted some other fixes, including:

… and a few more including a couple of small extensions to coroutines and networking. Note that those two TSes were already published, and are not yet merged into the C++ draft standard, but we are still maintaining those experimental TS “branches” with fixes and updates, so that those will be done and ready once we are ready to merge those TS branches into the C++ “trunk” project itself.

Other major full committee approvals

We approved Parallelism TS 2 to be extended with the (huge) extensions in Data-parallel vector types and operations (Matthias Kretz) and declared it feature-complete: It is now being sent out for its main ISO comment ballot.

We also decided to officially open a Reflection TS work item, which means that the committee as a whole is taking ownership of the proposal and intends to progress it as a TS. The initial content is from the paper “Static reflection” (Matúš Chochlík, Axel Naumann, David Sankel) but everyone should understand that the surface syntax will change. The primary point of the TS is in the underlying “engine” and functionality, and the intention is to replace the placeholder template-metaprogramming-like reflexpr syntax with an object-like model that looks like “more constexpr code” — regular C++ code that is able to be run at compile time.

Language/library evolution subgroup approvals

Here is a list of proposals that achieved Evolution or Library Evolution working group (EWG or LEWG) design approval. This means that the subgroup responsible for approving the design has done so (sometimes provisionally, with a few “revision is expected” notes below), and the next step is that they now enter wording review in the Core or Library working group (CWG or LWG), and are slated to be proposed for formal adoption in C++20 at a future meeting. Thanks to Olivier Giroux, Ville Voutilainen, Titus Winters for their notes that contributed to this summary.

For contracts, EWG discussed a clarification to what the result of observable side-effects in contract pre/post-conditions is, and the guidance is that it’s undefined behavior.

For reflection and related facilities, EWG approved some papers that are significant milestones for compile-time programming:

EWG also approved:

We also decided to pursue putting in writing two statements about how we evolve C++:

  • EWG decided to pursue turning “C++ Stability, Velocity, and Deployment Plans” (Titus Winters) into a Standing Document, with the expectation is that the document will be revised and reviewed again. Titus Winters will be the main author, and Gabriel Dos Reis, Bjarne Stroustrup, and Mike Spertus will assist.
  • EWG also supports turning “Standard library compatibility promises” (Titus Winters) into a Standing Document, and to add the promises also to the standard’s own Library Introduction clause. Titus Winters will be the main author, with help from Ashley Hedberg, Nevin Liber, Bjarne Stroustrup, James Dennett, Walter E. Brown, Gor Nishanov, Alisdair Meredith, Mike Spertus, Robert Steagall and Daveed Vandevoorde.

We decided to launch a systematic effort to drive out the remaining uses of macros by providing replacements for those uses. We requested an analysis paper listing all the remaining use cases for macros are, a description of the status of the non-macro solutions for those problems, and possible solutions. This paper will be led by Ville Voutilainen, assisted by Bjarne Stroustrup, Gabriel Dos Reis, James Dennett, and Vittorio Romeo.

Somewhat stunningly (to me), we decided to pursue some cleanup to the C fundamental types that would be a breaking change to certain kinds of C and C++17 code. It came up via the discussion of “Towards consistency between <=> and other comparison operators” (Richard Smith), which observed that when we added <=> to C++20, in <=> only we deliberately decided not to repeat the well-known issues that we did not want to perpetuate with C’s two-way comparisons for fundamental types (e.g., signed-unsigned comparison surprises like -1 < 0u giving the “wrong” answer)… which naturally meant that we now have inconsistencies between the preexisting two-way comparison operators and the shiny new three-way <=> operator. When faced with this, the subgroup discovered that we had a consensus in the room that enough really was enough, and we decided to seriously investigate doing some housecleaning and fix those things even though that would include breaking changes to (mostly ill-behaved) C and C++17 code. For example, we are now on a path to pursue deprecating or outright removing the ability to compare two unrelated enumerations (which is just plain suspicious code), and to require -1 < 0u to give the mathematically correct answer even when in the worst case that means generating two comparison machine instructions instead of just one (any code that does such ill-advised things would change from being a correctness problem into “just” a one-extra-instruction performance problem). — We have made no decisions about actually doing this or the ship vehicle for such changes, which likely would have to be rolled out in stages via deprecation followed by removel, and we expect more data to be gathered before Rapperswil regarding how much code could be affected. But as far as I can recall, this is the most breaking-change cleanup to C’s fundamental types that we have ever been willing to seriously consider.

LEWG approved Standard library concepts (Casey Carter). This is the first part of the Ranges TS to be on track for merging into C++20 at an upcoming meeting, and contains the core concepts from the Ranges TS. It is also the first appearance of the concepts language feature in the standard library.

Other progress

Also for concepts, at this meeting EWG approved pursuing a direction based on my paper “Concepts in-place syntax” (Herb Sutter) to have a shorthand syntax for declaring constrained templates.

At this meeting, we considered further improvements to the modules design, including a renewed proposal focusing on a bridge to help existing header-based code move toward a modules-enabled world. By the end of the meeting, the main participants had hammered out a plan to, over the next few meetings:

  • move a core set of modules functionality into C++20 that is “clean” and uncompromised by legacy concerns; and
  • concurrently update the remaining modules TS with features specific to transitioning header-based code to modules, which might include support for macros.

There’s a lot of work remaining, but we’ll know in the next few meetings how the objectives are progressing.

After several years of incubation, executors are now making strong progress and are on track to become a TS in the C++20 timeframe. (Let me explicitly say “thread pools” for the benefit of those who are Ctrl-F’ing to find out how C++ intends to support modern thread pools such as in Windows 10 and Grand Central Dispatch. You’re now in the right place: Modern thread pool support is coming as part of executors.)

Note that there is a dependency on executors before we can merge the networking TS and the future.then feature in the concurrency TS into the C++ draft standard, which means that all of those features are likely to be merged early in the C++23 cycle rather than in C++20.

We are going to try to ship coroutines in C++20.

We are opening a new work item for Library Fundamentals TS3, the third batch of library additions, even as we will soon be starting to fold in material from the recently-published Library Fundamentals TS2 into C++20.

SG15 (Tooling) (Titus Winters) had its first meeting, and there is a shared belief that we need to take concrete steps toward enabling better support for tools for two things in particular: modules, and C++ library package managers. That coincided very nicely with the 2018-02 isocpp.org survey, where on the open-ended question 10, the #1 write-in answer was to request “dependencies / package manager” (15% of all write-ins mentioned that). Clearly there is interest in this area, and it will be interesting to see how this develops into proposals over the coming meetings.

We also created a new study group SG16 (Unicode) with Tom Honermann as the SG chair.

What’s next

Whew! Here is a cheat-sheet summary of our current expectations for some of the major pieces of work that are not already in draft C++20. Note that this is an estimate only.

cpp11147020 - 201803

And here is an updated snapshot of where we are on the timeline for C++20 and the TSes that are completed, in flight, or expected to begin:


Finally, here is the schedule for the C++20 cycle approved by unanimous consent at this meeting:


Thank you again to the approximately 140 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good spring… we look forward now to our next meetings in June (Rapperswil, Switzerland) and November (San Diego, CA, USA).