Pre-trip report: Fall ISO C++ standards meeting (San Diego)

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.