Obligatory comment: The C++20 Eagle has wings.

At noon today, July 20 2019, the ISO C++ committee completed its summer meeting in Cologne, Germany, hosted with thanks by Think-Cell, SIGS Datacom, SimuNova, Silexica, Meeting C++, Josuttis Eckstein, Xara, Volker Dörr, Mike Spertus, and the Standard C++ Foundation.

As usual, we met for six days Monday through Saturday, and it was our biggest meeting yet with some 220 attendees. Here’s a visual, going back to when I first joined the committee:

For more details about how we have adapted organizationally to handle our size increase, 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:

• See also the Reddit trip report, which was collaboratively edited by several dozen committee members. It has lots of excellent detail.
• 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.

The main news: C++20 is feature complete, CD ships

Today we achieved feature freeze for C++20.

Per our official C++20 schedule, we are now feature-complete for C++20 and will send out the C++20 draft for its international comment ballot (Committee Draft, or CD) to run over the summer. After that, we will address national body comments and other fit-and-finish work for the next two meetings (November in Belfast, and February in Prague) and plan to ship the final text of the C++20 start at the end of the February meeting.

Here are the main proposals that were added into C++20 at this meeting.

std::format for text formatting (Victor Zverovich) adds format strings support to the C++ standard library, including for type-safe and positional parameters. If you’re familiar with Boost.Format or POSIX format strings, or even just printf, you’ll know exactly what this is about: It gives us the best of printf (convenience) and the best of iostreams (type safety and extensibility of iostreams) – and it isn’t limited to iostreams, it lets you format any string. I’ve been waiting for this for a long time, so that I will never have to use header iomanip again.

Applying <=> (spaceship) comparisons throughout the standard library (Barry Revzin) uses the new <=> feature and applies it throughout namespace std to basically everything. It’s great to see a new language feature we added in C++20 already used widely in the standard library itself in the same release. And it’s not alone: C++20 also added concepts and also the concepts-based ranges library in the same release.

Stop token and joining thread (Nicolai Josuttis, Lewis Baker, Billy O’Neal, Herb Sutter, Anthony Williams) brings us two presents: First, a correctly RAII thread type whose destructor implicitly joins if you haven’t joined or detached already. And second, but even more importantly, a general composable cancellation mechanism into the standard library that all types can use, called stop_token.

And also, in the “moar constexpr!” and “constexpr all the things!” departments:

We added constexpr INVOKE (Tomasz Kamiński and Barry Revzin), constexpr std::vector (Louis Dionne), and constexpr std::string (Louis Dionne). If all this constexpr surprises you, and in particular if constexpr std::vector and std::string make you do a double-take: Remember that we already added constexpr new (think about that and grok what it means) and made much of the standard library constexpr and added consteval to the language… and all told this means that a whole lot of ordinary C++ code can run at compile time, now including even the standard dynamic vector and string containers. This is something that would have been difficult to imagine just a few years ago, but it shows ever more that we’re on a path where we can run plain C++ code at compile time instead of trying to express those computations as template metaprograms. As many people have said: “More metaprogramming, less template metaprogramming!” We didn’t have to invent a new ‘compile-time C++’ dialect; this is just C++, running at compile time. This trend is good.

There are dozens of additional proposals we adopted besides these, all of them good work, and I want to repeat our great thanks to all the proposal authors and also the even larger number of people who helped them with their proposals without whom this could not have happened. Thank you for your time and effort on behalf of millions of C++ developers worldwide who will benefit from your hard and careful work!

Contracts moved from draft C++20 to a new Study Group

At this meeting, it became clear that we were not quite done designing the contracts feature in time for C++20. Back when we adopted the feature one year ago we thought it was baked and ready for the standard, but since then we have discovered lingering design disagreements and concerns that we could not resolve sufficiently to get consensus (general agreement without sustained objections). All the main contracts proposers unanimously agreed that the right thing to do is to defer its release.

But contracts is an important feature, and work on contracts is not stopping, but actually increasing: The contracts proposers made good progress at this meeting toward starting to identify and iron out the differences, and we formed a new Study Group for Contracts, SG21, with John Spicer as the chair that will continue work with even greater participation. I’m hopeful that over the coming meetings we’ll see some solid further progress in this important area.

The shape of C++20

Now that we know the final feature set of C++20, we can see this is C++’s largest release since C++11. “Major” features include:

• modules
• coroutines
• concepts including in the standard library via ranges
• <=> spaceship including in the standard library
• broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip reports)
• ranges
• calendars and time zones
• text formatting
• 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 alongside the previous two (C++98 and C++11). 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.

It was not lost on the room that today was not just the day we completed the feature set of C++20, but it was also the 50^th anniversary of the Apollo 11 lunar landing. A number of people mentioned it throughout the week and especially today, some citing examples from that voyage and drawing parallels that ranged from insightful to side-splittingly funny. Here is one that I contributed after we had the vote to adopt the draft, with profuse apologies to Neil Armstrong that I couldn’t come up with something even better (sorry!):

There’s no doubt about it, C++20 is a big release with many new and important features. It’s almost done as we now enter the review and fit-and-finish phases… as we complete the work to ship the new standard over the coming two meetings, and as it then gradually becomes available for you to use in C++ implementations, we hope you will find it a useful and compelling release.

Oh, and here’s a public service announcement… even without contracts we can still make “co” jokes:

As someone pointed out to me after the session ended: This was, after all, the co_logne meeting.

Other progress and decisions

Because for the past year we’ve been focused on finishing C++20, I’ve been holding back from publishing updates to my own P0707 and P0709 proposals, generation+metaclasses and lightweight exception handling. At this meeting, I brought updates to both of those proposals again. In Study Group 7 (Compile-Time Programming) I showed an updated of P0707 and Andrew Sutton and Wyatt Childers presented updates on the Clang-based implementation progress. In the Evolution subgroup, I presented P0709 for the first time and received broad encouragement for most of the proposal along with a list of questions to which I’ll come back with answers in Belfast.

Thank you again to the approximately 220 experts who attended this meeting, and the many more who participate in standardization through their national bodies! If today our C++20 Eagle has wings, our next step is to land it, then bring it home… and so in our next two regular WG21 meetings, in November (Belfast, Northern Ireland, UK) and February (Prague, Czech Republic), we plan to respond to the C++20 international review ballot comments and make other bugfixes before sending final C++20 out for its approval ballot about seven months from now.

Have a good summer… and see many of you (and a large part of the committee) at CppCon in September!

WG21 has a strict schedule (see P1000) by which we ship the standard every three years. We don’t delay it.

Around this time of each cycle, we regularly get questions about “but why so strict?”, especially because we have many new committee members who aren’t as familiar with our history and the reasons why we do things this way now. And so, on the pre-Cologne admin telecon last Friday, several of the chairs encouraged me to write down the reasons why we do it this way, and some of the history behind the decision to adopt this schedule.

I’ve now done that by adding a FAQ section to the next draft of P1000, and I’ve sent a copy of it to the committee members now en route to Cologne. That FAQ material will appear in the next public revision of P1000 which will be in the post-meeting mailing a few weeks from now.

In the meantime, because the draft FAQ might be of general public interest too, here is a copy of that material. I hope you find it largely useful, occasionally illuminating, and maybe even a bit entertaining.

Now off to the airport… see (many of) you in Cologne. We are expecting about 220 people… by far our largest meeting ever. More about that in the post-meeting trip report after the meeting is over…

---

FAQs

(As of pre-Cologne, July 2019) There are bugs in the standard, so should we delay C++20?

Of course, and no.

We are on our planned course and speed: Fixing bugs is the purpose of this final year, and it’s why this schedule set the feature freeze deadline for C++“20” in early “19” (Kona), to leave a year to fix bugs including to get a round of international comments this summer. We have until early 2020 (three meetings: Cologne, Belfast, and Prague) to apply that review feedback and any other issue resolutions and bug fixes.

If we had just another meeting or two, we could add <feature> which is almost ready, so should we delay C++20?

Of course, and no.

Just wait a couple more meetings (post-Prague) and C++23 will be open for business and <feature> can be the first thing voted into the C++23 working draft. For example, that’s what we did with concepts; it was not quite ready to be rushed from its TS straight into C++17, so the core feature was voted into draft C++20 at the first meeting of C++20 (Toronto), leaving plenty of time to refine and adopt the remaining controversial part of the TS that needed a little more bake time (the non-“template” syntax) which was adopted the following year (San Diego). Now we have the whole thing.

This feels overly strict. Why do we ship releases of the IS at fixed time intervals (3 years)?

Because it’s one of only two basic project management options to release the C++ IS, and experience has demonstrated that it’s better than the other option.

What are the two project management options to release the C++ IS?

I’m glad you asked.

There are two basic release target choices: Pick the features, or pick the release time, and whichever you pick means relinquishing control over determining the other. It is not possible to control both at once. They can be summarized as follows:

Elaborating:

(1) “What”: Pick the features, and ship when they’re ready; you don’t get to pick the release time. If you discover that a feature in the draft standard needs more bake time, you delay the world until it’s ready. You work on big long-pole features that require multiple years of development by making a release big enough to cover the necessary development time, then try to stop working on new features entirely while stabilizing the release (a big join point).

This was the model for C++98 (originally expected to ship around 1994; Bjarne originally said if it didn’t ship by about then it would be a failure) and C++11 (called 0x because x was expected to be around 7). This model “left the patient open” for indeterminate periods and led to delayed integration testing and release. It led to great uncertainty in the marketplace wondering when the committee would ship the next standard, or even if it would ever ship (yes, among the community, the implementers, and even within the committee, some had serious doubts in both 1996 and 2009 whether we would ever ship the respective release). During this time, most compilers were routinely several years behind implementing the standard, because who knew how many more incompatible changes the committee would make while tinkering with the release, or when it would even ship? This led to wide variation and fragmentation in the C++ support of compilers available to the community.

Why did we do that, were we stupid? Not exactly, just inexperienced and… let’s say “optimistic,” for (1) is the road paved with the best of intentions. In 1994/5/6, and again in 2007/8/9, we really believed that if we just slipped another meeting or three we’d be done, and each time we ended up slipping up to four years. We learned the hard way that there’s really no such thing as slipping by one year, or even two.

Fortunately, this has changed, with option (2)…

(2) “When”: Pick the release time, and ship what features are ready; you don’t get to pick the feature set. If you discover that a feature in the draft standard needs more bake time, you yank it and ship what’s ready. You can still work on big long-pole features that require multiple releases’ worth of development time, by simply doing that work off to the side in “branches,” and merging them to the trunk/master IS when they’re ready, and you are constantly working on features because every feature’s development is nicely decoupled from an actual ship vehicle until it’s ready (no big join point).

This has been the model since 2012, and we don’t want to go back. It “closes the patient” regularly and leads to sustaining higher quality by forcing regular integration and not merging work into the IS draft until it has reached a decent level of stability, usually in a feature branch. It also creates a predictable ship cycle for the industry to rely on and plan for. During this time, compilers have been shipping conforming implementations sooner and sooner after each standard (which had never happened before), and in 2020 we expect multiple fully conforming implementations the same year the standard is published (which has never happened before). This is nothing but goodness for the whole market – implementers, users, educators, everyone.

Also, note that since we went to (2), we’ve also been shipping more work (as measured by big/medium/small feature counts) at higher quality (as measured by a sharp reduction in defect reports and comments on review drafts of each standard), while shipping whatever is ready (and if anything isn’t, deferring just that).

How serious are we about (2)? What if a major feature by a prominent committee member was “almost ready”… we’d be tempted to wait then, wouldn’t we?

Very serious, and no.

We have historical data: In Jacksonville 2016, at the feature cutoff for C++17, Bjarne Stroustrup made a plea in plenary for including concepts in C++17. When it failed to get consensus, Stroustrup was directly asked if he would like to delay C++17 for a year to get concepts in. Stroustrup said No without any hesitation or hedging, and added that C++17 without concepts was more important than a C++18 or possibly C++19 with concepts, even though Stroustrup had worked on concepts for about 15 years. The real choice then was between: (2) shipping C++17 without concepts and then C++20 with concepts (which we did), or (1) renaming C++17 to C++20 which is isomorphic to (2) except for skipping C++17 and not shipping what was already ready for C++17.

What about something between (1) and (2), say do basically (2) but with “a little” schedule flexibility to take “a little” extra time when we feel we need to stabilize a feature?

No, because that would be (1).

The ‘mythical small slip’ was explained by Fred Brooks in The Mythical Man-Month, with the conclusion: ”Take no small slips.”

For a moment, imagine we did slip C++20. The reality is that we would be switching from (2) back to (1), no matter how much we might try to deny it, and without any actual benefit. If we decided to delay C++20 for more fit-and-finish, we will delay the standard by at least two years. There is no such thing as a one-meeting or three-meeting slip, because during this time other people will continue to (rightly) say “well my feature only needs one more meeting too, since we’re slipping a meeting let’s add that too.” And once we slip at least two years, we’re saying that C++20 becomes C++22 or more likely C++23… but we’re already going to ship C++23! — So we’d still be shipping C++23 on either plan, and the only difference is that we’re not shipping C++20 in the meantime with the large amount of fully-baked work that’s ready to go, and making the world wait three more years for it. Gratuitously, because the delay will not benefit those baked features, which is most or all of them.

So the suggestion amounts to “let’s make C++20 be C++22 or C++23,” and the simple answer is “yes, we’re going to have C++23 too, but in addition to C++20 and not instead of it.” To delay C++20 actually means to skip C++20, instead of releasing the great good work that is stable and ready, and there’s no benefit to doing that.

But feature X is broken / needs more bake time than we have bugfix time left in C++20!

No problem! We can just pull it.

In that case, someone needs to write the paper aimed at EWG or LEWG (as appropriate) that shows the problem and/or the future doors we’re closing, and proposes removing it from the IS working draft. Those groups will consider it, and if they decide the feature is broken (and plenary agrees), that’s fine, the feature will be delayed to C++next. We have actually done this before, with C++0x concepts.

But under plan (1), we would be delaying, not only that feature, but the entire feature set of C++20 to C++23! That would be… excessive.

Does (2) mean “major/minor” releases?

No. We said that at first, before we understood that (2) really simply means you don’t get to pick the feature set, not even at a “major/minor” granularity.

Model (2) simply means “ship what’s ready.” That leads to releases that are:

• similarly sized (aka regular medium-sized) for “smaller” features because those tend to take shorter lead times (say, < 3 years each) and so generally we see similar numbers completed per release; and
• variable sized (aka lumpy) for “bigger” features that take longer lead times (say, > 3 years each) and each IS release gets whichever of those mature to the point of becoming ready to merge during that IS’s time window, so sometimes there will be more than others.

So C++14 and C++17 were relatively small, because a lot of the standardization work during that time was taking place in long-pole features that lived in proposal papers (e.g., contracts) and TS “feature branches” (e.g., concepts).

C++20 is a big release …

Yes. C++20 has a lot of major features. Three of the biggest all start with the letters “co” (concepts, contracts, coroutines) so perhaps we could call it co_cpp20. Or co_dependent. Wait, we’re digressing.

… and so aren’t we cramming a lot into a three-year cycle for C++20?

No, see “lumpy” above.

C++20 is big, not because we did more work in those three years, but because many long-pole items (including at least two that have been worked on in their current form since 2012, off to the side as P-proposals and TS “branches”) happened to mature and get consensus to merge into the IS draft in the same release cycle.

It has pretty much always been true that major features take many years. The main difference between plan (1) for C++98 and C++11 and plan (2) now is: In C++98 and C++11 we held the standard until they were all ready, now we still ship those big ones when they’re ready but we also ship other things that are ready in the meantime instead of going totally dark.

C++20 is the same 3-year cycle as C++14 and C++17; it’s not that we did more in these 3 years than in the previous two 3-year cycles, it’s just that more long-pole major features became ready to merge. And if any really are unready, fine, we can just pull them again and let them bake more for C++23. If there is, we need that to be explained in a paper that proposes pulling it, and why, for it to be actionable.

In fact, I think the right way to think about it is that C++14+17+20 taken as a whole is our third 9-year cycle (2011-2020), after C++98 (1989-1998) and C++11 (2002-2011), but because we were on plan (2) we also shipped the parts that were ready at the 3- and 6-year points.

Isn’t it better to catch bugs while the product is in development, vs. after it has been released to customers?

Of course.

But if we’re talking about that as a reason to delay the C++ standard, the question implies two false premises: (a) it assumes the features haven’t been released and used before the standard ships (many already have production usage experience); and (b) it assumes all the features can be used together before the standard ships (they can’t).

Elaborating:

Re (a): Most major C++20 features have been implemented in essentially their current draft standard form in at least one shipping compiler, and in most cases actually used in production code (i.e., has already been released to customers who are very happy with it). For example, coroutines (adopted only five months ago as of this writing) has been used in production in MSVC for two years and in Clang for at least a year with very happy customers at scale (e.g., Azure, Facebook).

Re (b): The reality is that we aren’t going to find many feature interaction problems until users are using them in production, which generally means until after the standard ships, because implementers will generally wait until the standard ships to implement most things. That’s why when we show any uncertainty about when we ship, what generally happens is that implementations wait – oh, they’ll implement a few things, but they will hit Pause on implementing the whole thing until they know we’re ready to set it in stone. Ask <favorite compiler> team what happened when they implemented <major feature before it was in a published standard>. In a number of cases, they had to implement it more than once, and break customers more than once. So it’s reasonable for implementers to wait for the committee to ship.

Finally, don’t forget the feature interaction problem. In addition to shipping when we are ready, we need time after we ship to find and fix problems with interactions among features and add support for such interactions that we on typically cannot know before widespread use of new features. No matter how long we delay the standard, there will be interactions we can’t discover until much later. The key is to manage that risk with design flexibility to adjust the features in a compatible way, not to wait until all risk is done.

The standard is never perfect… don’t we ship mistakes?

Yes.

If we see a feature that’s not ready, yes we should pull it.

If we see a feature that could be better, but we know that the change can be done in a backward-compatible way, that’s not a reason to not ship it now; it can be done as an extension in C++next.

We do intentionally ship features we plan to further improve, as long as we have good confidence we can do so in a backward-compatible way.

But shouldn’t we aim to minimize shipping mistakes?

Yes. We do aim for that.

However, we don’t aim to eliminate all risk. There is also a risk and (opportunity) cost to not shipping something we think is ready. So far, we’ve been right most of the time.

Are we sure that our quality now is better than when were on plan (1)?

Yes.

By objective metrics, notably national body comment volume and defect reports, C++14 and C++17 have been our most stable releases ever, each about 3-4 times better on those metrics than C++98 or C++11. And the reason is because we ship regularly, and put big items into TS branches first (including full wording on how they integrate with the trunk standard) and merge them later when we know they’re more baked.

In fact, since 2012 the core standard has always been maintained in a near-ship-ready state (so that even our working drafts are at least as high quality as the shipped C++98 and C++11 standards). That never happened before 2012, where we would often keep the patient open with long issues lists and organs lying around nearby that we meant to put back soon; now we know we can meet the schedule at high quality because we always stay close to a ship-ready state. If we wanted to, we could ship the CD right now without the Cologne meeting and still be way higher quality than C++98’s or C++11’s CDs (or, frankly, their published standards) ever were. Given that C++98 and C++11 were successful, recognizing that we’re now at strictly higher quality than that all the time means we’re in a pretty good place.

C++98 and C++11 each took about 9 years and were pretty good products …

Yes: 1989-1998, and 2002-2011.

… and C++14 and C++17 were minor releases, and C++20 is major?

Again, I think the right comparable is C++14+17+20 taken as a whole: That is our third 9-year cycle, but because we were on plan (2) we also shipped the parts that were ready at the 3- and 6-year points.

Does (2) allow making feature-based targets like P0592 for C++next?

Sure! As long as it doesn’t contain words like “must include these features,” because that would be (1).

Aiming for a specific set of features, and giving those ones priority over others, is fine – then it’s a prioritization question. We’ll still take only what’s ready, but we can definitely be more intentional about prioritizing what to work on first so it has the best chance of being ready as soon as possible.

The ISO C++ committee now regularly receives many more proposals than we can/should accept. For the meeting that begins this coming Monday, we have about 300 active technical papers, most targeting post-C++20. I now regularly get asked, including again a few hours ago, “how do we know which of these customers actually want and will use? what is our data that we’ve prioritized them correctly?”

So a colleague has challenged me: Can the ISO C++ committee get useful information by crowdsourcing public feedback on ISO C++ proposals? I don’t know, so let me try by asking one targeted question…

Survey: If you could pick at most five of [list of active papers] to be eventually adopted in the C++ standard in some form, which would you pick and why (ideally, how you would use them in production)?

I don’t expect you to know all of the proposals (and I know it’s a big list!), but I suspect many of you know about some of them that matter to you. I will share your feedback with the ISO C++ committee and post the results publicly. Thanks again for all of you who’ve already provided feedback in our spring C++ developer survey, that feedback is being used by the committee and the experiment here is try for finer-grained feedback at the proposal level. If this works perhaps we can explore things like allowing community comment/upvote on these issues.

Thank you in advance for your time, it’s appreciated and helpful.

Herb

Note: PLEASE use the survey (not the comments section on this post) to respond to this question, because the survey form makes it easier to track and use the data.

Please do use the comments section below for other discussion, including suggestions about other ways the committee might usefully engage the community.

Classic, and timeless. (HT: Patricia Aas, Tony Van Eerd and Peter Sommerlad)

Note that when he says “growing a language” he doesn’t mean literally the language itself — it’s not a talk about language evolution. Rather, he’s talking about enabling users to write rich and powerful abstractions in that language without having to go beg their language designer and compiler vendor to build them into the compiler every time.

Steele’s argument in the back half of the talk is on point, on the importance of imbuing a programming language with a few well-chosen “patterns” that allow, and guide, specific kinds of extensibility. His argument is a great description of why I’m pursuing metaclasses for C++, because we should have a convenient way for programmers to write their own Words of Power like “value_type” or “interface” as libraries instead of forcing them to go bother their local compiler writer (or local standards committee) for a language extension each time for that sort of thing. And his “as a pattern” description is a great summary of why I’m proposing them as “just” a sugar to apply a compile-time function in a very specific place and in a very constrained way, and not going anywhere near making a mutable language which would be crazy not worth pursuing.

This week I was happy to join Rob Irving and Jason Turner on their great CppCast podcast. I chose “Simplifying C++” as the theme, because all of the active work I’ve chosen to do on C++ these days is on the common theme of simplifying how we teach, learn, and use C++… the “C++ UX” you might say.

Here’s the podcast: CppCast: Simplifying C++ with Herb Sutter (length: 1:07)

And here’s a table that summarizes my active projects that we mentioned in the podcast, and what specific parts of C++ that I hope each might help simplify.

You’ll notice that three common “simplification” themes get their own summary columns: Can this project reduce what we have to teach/know to use C++, so that C++ can be easier to learn and use? Can it reduce or even eliminate classes of errors, so that we can program with greater confidence? And can it reduce the need for future language features, to help reduce future complexity as C++ continues to grow and evolve?

Finally, here is the list with links:

Elements of Modern C++ Style and C++ Core Guidelines (CppCon 2014, 2015)

Lifetime profile and gcpp opt-in tracing GC allocator (CppCon 2015, 2016, 2018)

Spaceship <=> comparisons (CppCon 2017, adopted C++20)

Reflection+metaclasses (ACCU 2017, CppCon 2017 & 2018)

Lightweight exception handling (ACCU 2019, CppCon 2019) Lightweight RTTI (CppCon 2019)

Incidentally, this pattern is why I chose the title “Thoughts on a more powerful and simpler C++ (5 of N)” for my CppCon talk last year — it was the 5th CppCon plenary session I’d given on this theme, so I thought I might as well make the theme explicit.

I hope you enjoy the podcast.

At CppCon 2018, I gave an update of my Lifetime analysis work that makes common cases of pointer/iterator/range/etc. dangling detectable at compile time (the spec is here in the C++ Core Guidelines GitHub repo). During that talk, we mentioned and demo’d two implementations: as a Visual C++ extension by Kyle Reed and Neil MacIntosh, and in a fork of Clang by Matthias Gehre and Gábor Horváth who both also joined me on-stage.

Last month at EuroLLVM, Matthias and Gábor gave a 30-minute progress report talk about their work to upstream the Lifetime rules implementation into Clang, “Implementing the C++ Core Guidelines’ Lifetime Safety Profile in Clang.” They give a summary of the approach and how it maps to Clang internals, show initial results from testing against Clang’s and LLVM’s own sources, and end with a nice roadmap for the next steps of incrementally upstreaming the work to Clang trunk.

If you care about making C++ safer, I recommend taking a look… it’s a great summary and update. Thanks, Matthias and Gábor and Kyle and Neil for their collaboration on this project!

Two weeks ago, I gave a talk at ACCU based on my paper P0709. The talk video was posted today:

De-fragmenting C++: Making exceptions more affordable and usable [ACCU 2019]

Thanks again to ACCU for inviting me and recording the talk, and for all the fun interactions and conversations with everyone at the conference!

A few minutes ago, the ISO C++ committee completed its winter meeting in Kona, HI, USA, hosted with thanks by Plum Hall, NVIDIA, and the Standard C++ Foundation. As usual, we met for six days Monday through Saturday, including most evenings. This and the previous meeting were the biggest ISO C++ meetings in our 29-year history, and this time we had a new record of 13 voting national bodies represented in person: Bulgaria, Canada, Czech Republic, Finland, France, Germany, Netherlands, Poland, Russia, Spain, Switzerland, United Kingdom, and United States. For more details about our size increase, including how we adapted organizationally to handle the load, see my San Diego “pre-trip” report and my San Diego trip report.

Thank you to all of the hundreds of people who participate in ISO C++ in person and electronically. Below, I want to at least try to recognize by name many of the authors of the proposals we adopted, but nobody succeeds with a proposal on their own. C++ is a team effort – this wouldn’t be possible without all of your help. So, thank you, and apologies for not being able to acknowledge everyone by name.

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.

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

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!

Notes:

• 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 6^th 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.