Jump to Table of Contents Pop Out Sidebar

P2145R0
Evolving C++ Remotely

Published Proposal,

Authors:
(NVIDIA)
(Google)
(CODE University of Applied Sciences)
(FlightSafety)
(Argonne National Laboratory)
(Apple)
(Uber)
(Mozilla)
(Intel)
(Synopsys)
Source:
GitHub
Issue Tracking:
GitHub
Project:
ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
Audience:
WG21

1. Introduction

Due to the ongoing global health crisis caused by the novel coronavirus, the ISO C++ Committee’s planned June 2020 meeting in Varna, Bulgaria was called off. During this uncertain time, our priority must be the safety and well-being of the committee and the public at large.

The postponement of the 2020-06 Varna meeting and the broader impacts of the novel coronavirus on society will be disruptive. At times like these, family and personal well-being comes first, and work comes second. No one can be as productive in these times as they normally would be. However, the ISO C++ Committee can and will do our best to adapt to these disruptions and carry on our work remotely in these trying times.

Our plans for C++23 and beyond ([P0592R4]) have not changed, but the way that we execute on those plans will have to change. This document lays out plans for how we will conduct Library and Language Evolution work remotely.

This proposal covers plans for remote operations until the schedule New York meeting in November 2020 [N4848]. We will revisit our plans should the 2020-11 New York meeting also be delayed.

2. Calendar

The telecon calendar is as follows:

The topics for each telecon can be found here:

Details about how to join the telecons will be distributed through the Library and Language Evolution email lists and wiki. If you do not have access to these and are interested in participating, please contact the authors of this paper.

April
Mo Tu We Th Fr Sa Su
1 2 3 4 5
6 7 8SG16 9 10 11 12
13 14 15 16 17 18 19
20CWG 21 22 23 24 25 26
27 28 29SG16 30
May
Mo Tu We Th Fr Sa Su
1 2 3
4 5 6 7 8 9 10
11 12SG16 13 14 15 16 17
18 19 20 21 22 23 24
25 26SG16 27 28 29 30 31
June
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6 7
8 9SG16 10 11 12 13 14
15 16 17 18 19 20 21
22 23SG16 24 25 26 27 28
29 30
July
Mo Tu We Th Fr Sa Su
1 2 3 4 5
6 7 8 9 10 11 12
13 14SG16 15 16 17 18 19
20 21 22 23 24 25 26
27 28SG16 29 30 31
August
Mo Tu We Th Fr Sa Su
1 2
3 4 5 6 7 8 9
10 11SG16 12 13 14 15 16
17 18 19 20 21 22 23
24 25SG16 26 27 28 29 30
31
September
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6
7 8SG16 9 10 11 12 13
14 15 16 17 18 19 20
21 22SG16 23 24 25 26 27
28 29 30
October
Mo Tu We Th Fr Sa Su
1 2 3 4
5 6 7 8 9 10 11
12 13SG16 14 15 16 17 18
19 20 21 22 23 24 25
26 27SG16 28 29 30 31

We will also provide a Google Calendar that people can subscribe to if they wish, and we will be emailing calendar invites to the language and library reflectors. Those will contain the link to the teleconference.

3. The Short Version

4. Work Performed at Face-to-Face Meetings

First, we need to understand what exactly we’re losing with the postponement of the 2020-06 Varna meeting. What exactly do we do at face-to-face meetings, and how much time do we spend doing it?

4.1. Amount of Work Performed at Face-to-Face Meetings

At a typical ISO C++ Committee face-to-face meeting, Library Evolution and Language Evolution meet for 33.25 hours each. Library Incubator meets for 24.8 hours. Language Incubator has similar numbers. For both the Library and Language tracks, we spend a total of ~58 hours per meeting and ~174 hours per year at face-to-face meetings on Evolution and Incubation.

A lot of voluntary and informal, but important, work also occurs during meals and at in the evening hours.

4.2. Kinds of Work Performed at Face-to-Face Meetings

When in session at face-to-face meetings, we typically perform three activities:

5. Mechanisms for Remote Collaboration

We have three primary mechanisms for remote collaboration:

6. Telecons

Because telecons are the only good option for decision-making and they are a scarce resource, we should try to use them for decision-making as much as possible. That means we should do as much distribution of information and review outside of telecons as possible. It is important that participants read the proposals that will be discussed on a telecon before the telecon, and utilize email list discussions whenever possible.

6.1. Telecon Duration and Cadence

As mentioned earlier in § 4.1 Amount of Work Performed at Face-to-Face Meetings, we spend ~174 hours per year on Library and Language Evolution at face-to-face meetings. This is an average of ~3.3 hours per week (~4 months per committee meeting equivalent).

~3.3 hours per week is a slightly larger commitment than reasonable, especially given that other parts of the committee will also be meeting remotely. If some part of the information distribution and review that occurs at face-to-face committee meetings can happen via email list discussions message platforms instead of telecons, it should not be necessary for us to make up all of the time of face-to-face meetings via telecons.

There are tradeoffs in selecting a duration for individual telecons. Longer telecons can be harder to schedule and can strain the endurance of participants. Shorter telecons are easier to schedule and may draw greater attendance, but disrupt the continuity of discussions.

Given the committee’s global nature, it is difficult to find times that are convenient for all committee members. Instead of always holding weekly meetings at a single time, we should either meet multiple times per week or meet once per week but have two time slots which alternate each week. This will give us additional scheduling flexibility.

Given all of this, Library and Language Evolution will meet ~1.5 hours per week, from April 2020 until at least November 2020.

This is about 50% of time commitment that we would have made to the 2020-06 Varna meeting. If this cadence and duration proves to be too much, we will adjust by scaling back and cancelling meetings.

6.2. Telecon Platform

Our telecon platform needs to be able to support the following:

We will use Zoom, the official ISO telecon platform. Zoom supports most of these features and the committee has field experience § 9 Field Experience With Remote Work using this platform to hold telecons.

6.3. No Separate Incubator Telecons

The primary reason that Library and Language Evolution Incubator meets separately and concurrently with Library and Language Evolution is due to the time constraints of our physical meetings.

For remote meetings, we do not have the same kind of time constraints that force concurrent sessions of Evolution and Incubator groups. As such, there does not seem to be much value in holding separate telecons.

All telecon discussions will be considered joint exercises of Evolution and Evolution Incubator.

6.4. Telecon Decision-Making

We will make decisions on telecons via straw polls, just as we do at face-to-face meetings.

Any decisions made on telecons will be considered "Tentatively Ready".

For forwarding of proposals to other subgroups, this means that the paper will be forwarded on the ISO C++ GitHub for paper tracking, but marked with the "Tentatively Ready" tag. At the start of the next face-to-face meeting, we will briefly go through the list of "Tentatively Ready" proposals that were forwarded to see if anyone has new information or new perspectives that warrant revisiting those proposals.

For all "Tentatively Ready" decisions made on telecons, after the telecon a message will be sent to the relevant email lists with a summary of the decisions, to give anyone who did not attend the telecon a chance to voice their opinion.

6.5. Telecon Quorum

We expect to have lower attendance on telecons than we would have at face-to-face meetings.

We do not have readily accessible data for attendance in Library Evolution and Language Evolution. Typically, attendance in Library Evolution is between 15 and 30 people and attendance in Language Evolution is between 30 and 50 people. Average attendance in Library Incubator is 17 people. Language Incubator has similar numbers.

Quorum is not merely a function of the quantity of people in the room. For quorum, we need to have both the right people and the right quantity of them.

That said, if we have fewer than 15 participants on any given Library or Language Evolution telecon, it will be difficult for us to make meaningful decisions. In such a circumstance, we would avoid decision-making and instead use our time for review and information distribution.

6.6. Telecon Chairing

Running weekly telecons is not a small amount of effort. Fortunately, we have multiple chairs available for each track (Evolution chair, Evolution vice chair, Incubator chair, and Incubator vice chair), so we can distribute the burden amongst ourselves.

6.7. Telecons Aren’t Mandatory

If you are a stakeholder on a particular proposal or subject, you are strongly encouraged to attend telecons on that proposal or subject. However, telecon attendance is encouraged but not mandatory.

Missing a telecon does not prevent your voice from being heard. If a decision is made on a telecon and you feel you have a new perspective or new information that was not considered, you should make the committee aware via email list discussion. As with face-to-face meetings, we can always revisit decisions if we have new information.

7. Email List Discussions

We have always made use of email list discussions for inter-meeting work, but they are more important than ever now, and we should strive to do more work via email.

To help drive email list discussions and minimize the need for telecons, chairs will start curated discussions of papers on a regular basis. This is something Library Evolution has done in the past to help address backlogs.

7.1. What Email List Discussions Are Good For

As discussed earlier, email list discussions are an excellent medium for us to review proposals and distribute information. They are asynchronous, which means people can participate in email list discussions when it is convenient for them to do so.

Review over email likely works best when the discussion is very targeted. If you want to start an email list discussion of a proposal, it’s probably best to begin with a focused set of questions that you are seeking answers for.

Here are some examples of questions that are probably well suited to an email list discussion:

I was writing Proposal X and ran into Specific Problem Y. Can anyone suggest some solutions?

I was writing Proposal X and I was wondering how Specific Thing Y came to be in the standard. Does anyone know?

I noticed Perceived Problem X in the standard, and I was thinking about writing a proposal to fix it in Specific Way Y. What do y’all think about my solution?

I was considering proposing Feature X. Do y’all think this is worth standardizing?

I was reading Proposal X and I noticed some downsides to Approach Y in the proposal. I spoke with the author and he mentioned that we have to select between Approach Y (which has Specific Downsides A) and Approach Z (which has Specific Downsides B). The author and I wanted to know what the committee thought about these tradeoffs.

Decision X was made on Telecon A; I’m not sure I understand the rationale, can someone explain?

Decision X was made on Telecon A; was Specific Thing Y considered during the discussion?

Attached is an update of Proposal X, with the following changes based on discussion from Telecon A: List of Changes B. I’d like to call particular attention to Part Y and Open Question Z - please let me know if you have any thoughts or new information.

7.2. What Email List Discussions Aren’t Good For

However, email list discussions have downsides. The signal-to-noise ratio can be quite bad and it can be difficult to identify the consensus of an email list discussion and leave with clear outcomes.

Additionally, sometimes email list discussions are not effective due to lack of participation. This can happen when the discussion doesn’t have a clear scope or goal.

You shouldn’t necessarily expect someone else to guide the discussion for you; chairs will help to do so whenever possible, but we don’t always have the bandwidth for that. If you want to start an effective email list discussion, you should take responsibility for scoping and guiding it.

Here are some anti-patterns for email list discussions.

Let’s discuss Proposal X. What do you think about it?

Alternative: If you want to discuss the proposal, you’ve read it and probably have specific things in mind that you’d like to discuss. So, write a concise, thoughtful email summarizing the specific matters or questions that you think ought to be discussed.

[Very, very long wall of text on a subject.]

Alternative: Consider writing a paper.

Please don’t do Approach A and Design Choice B in Proposal X.

Alternative: Explain yourself! Make sure to describe your thought process and rationale, so that others understand your thinking. Instead of saying "don’t do A and B", suggest alternatives that the authors might explore.

7.3. Summarize Email List Discussions

Because email list discussions have bad signal-to-noise ratio and can be difficult to follow, it’s often hard to identify the outcomes of said discussions.

It is invaluable for someone to step in at or around the end of a discussion and write up a short email summarizing their understanding of everyone’s position and any outcomes. You can then send this summary and ask if everyone agrees with it. This can help bring much needed closure to discussions.

8. High-Priority Work

At the 2020-02 Prague meeting, the committee adopted a plan for C++ standardization, [P0592R4]. That plan contained seven high-priority items; four library items for C++23, and three language items for C++23 or later.

This section describes specific plans for these high-priority work items.

Once this material has been addressed, we will prioritize bug fixes, performance improvements, integration fixes for/between existing features, and issue processing.

8.1. High-Priority Library Work

8.1.1. Networking

The Networking study group has been reactivated to drive standardization of networking. This group will set the direction for work on networking; once they have consensus on a direction, they will bring that direction to Library Evolution.

We have an existing, large proposal for networking: the Networking Technical Specification ([N4734]).

In Fall 2019, we conducted an inter-meeting review of the Networking TS. We created a number of review groups, each of which was tasked with looking at a particular aspect of the Networking TS, resolving whatever issues they could, and identifying open questions that required broader review. Each group was asked to summarize its findings.

Approximately half of these groups presented their findings at the 2020-02 Prague meeting of the Networking study group. The Networking study group was able to reach consensus on some matters, and identified others that will eventually need review in Library Evolution. Each of these groups has been asked to prepare a paper containing their summary, to presented to Networking study group and Library Evolution.

Once all of these summaries have been produced and the Networking study group decides they are ready for Library Evolution, we will begin reviewing them in Library Evolution.

8.1.2. Executors

For executors, we have an existing, large proposal, [P0443R13] which is ready for Library Evolution review.

Given the scope of this proposal, we believe the best route to reviewing it is to form a number of review groups and ask each group to review a particular aspect of the proposal, resolve whatever issues they can, and identify open questions that require broader review. Each group will then prepare a paper summarizing their findings. Each group will consist of a number of executors authors and a number of Library Evolution regulars who are not involved in the executors proposal.

Given the nature of the executors proposal, the work of each group will be overlapping. Each group will not be reviewing a specific section, but instead reviewing the proposal from a particular perspective with a specific design facet in mind.

We have already started speaking with some of the executors authors about how we will structure this review. More details will be shared on the Library Evolution email list in the next few weeks.

Once all of the review groups have completed their work and prepared their summary papers, we will discuss the results in a series of telecons over the summer and work towards resolution of any open matters that need decisions and guidance.

8.1.3. Modularizing the Standard Library

Modularizing the standard library is a goal for C++23, but we have not yet decided on a concrete direction or scope for this work.

We are aware of the following papers on this topic:

The following papers related to freestanding are also applicable:

The first few big questions we have to address to help scope this work are:

We will hold telecons to reach consensus on these and other questions and define the scope of what we want to pursue.

8.1.4. Coroutine Library Support

Richer coroutine library support is a goal for C++23, but we have not yet decided on a concrete direction or scope for this work.

We are aware of the following papers on this topic, some of which are quite dated. They are grouped by subject:

Additionally, the desire for the following coroutine library features have been expressed multiple times. However, we lack a proposal for these features:

We need to identify what exactly we want here. What are our goals for coroutine library support? What features do we desire?

We will discuss scoping of this work on an upcoming telecon. Ideally we need a paper proposing what the scope and goals should be.

8.2. High-Priority Language Work

8.2.1. Pattern Matching

Language Evolution will continue to review [P1371R2] as it gets updated.

8.2.2. Reflection

We will let the Reflection study group pursue all work related to reflection. We will only start looking at matters pertaining to reflection in Language Evolution after the Reflection study group has forwarded them to us.

8.2.3. Contracts

We will let the Contracts study group pursue all work related to contracts. We will only start looking at matters pertaining to contracts in Language Evolution after the Contracts study group has forwarded them to us.

9. Field Experience With Remote Work

We are not in completely uncharted waters here. The ISO C++ Committee does have field experience working remotely. A lot of important inter-meeting discussion happens on email lists. The Tooling and Unicode study groups, among others, have successfully and regularly met and made decisions via telecons.

The main benefits of a face-to-face meeting over remote meetings are:

We can’t replicate these effects in remote meetings.

10. Deadlines

One of the biggest impacts of losing the face-to-face 2020 summer meeting is the loss of a major deadline. This is compounded by the transition to monthly mailing deadlines. It is now a lot easier for a paper author to "miss" a deadline; you can always publish it next month and have it discussed on a telecon.

We must be careful to avoid allowing this flexibility to lead to procrastination. Hard deadlines, even arbitrary ones, fight mission creep and ultimately produce deliverables.

In the absence of physical meetings, there are two types of deadlines we can use to drive work:

Telecons will be most effective if the schedule is known well in advance, but leaves some room for flexibility, just as the schedule is for a face-to-face meeting. Chairs will try to have a tentative agenda for the next 4 to 8 weeks of telecons. The tentative agendas can be found here:

11. Appendix

11.1. Typical Library and Language Evolution Face-to-Face Schedule

Day Hours
Monday 5.25
Tuesday 7
Wednesday 7
Thursday 7
Friday 7
Total 33.25

11.2. Historical Library Incubator Face-to-Face Schedule

Meeting Hours
2018-11 San Diego 22.75
2019-02 Kona 26.25
2019-07 Cologne 24.5
2019-11 Belfast 30
2020-02 Prague 20.5
Average 24.8

11.3. Historical Library Incubator Face-to-Face Attendance

Meeting # of Polls Average Attendance Minimum Attendance Maximum Attendance
2018-11 San Diego 62 14.6 11 19
2019-02 Kona 75 14 11 22
2019-07 Cologne 49 19.2 12 26
2019-11 Belfast 50 17.8 12 24
2020-02 Prague 46 20 12 25
Average 56.4 17.12 11.6 23.2

Index

Terms defined by this specification

References

Informative References

[N4734]
Jonathan Wakely. Working Draft, C ++ Extensions for Networking. 4 April 2018. URL: https://wg21.link/n4734
[N4848]
Kevin Fleming. WG21 Autumn Meeting 2020 - New York, New York, USA. 14 January 2020. URL: https://wg21.link/n4848
[P0055R1]
Gor Nishanov. On Interactions Between Coroutines and Networking Library. 12 February 2016. URL: https://wg21.link/p0055r1
[P0162R0]
Christopher Kohlhoff. A response to "P0055R0: On Interactions Between Coroutines and Networking Library". 6 November 2015. URL: https://wg21.link/p0162r0
[P0286R0]
Christopher Kohlhoff. A networking library extension to support co_await-based coroutines. 14 February 2016. URL: https://wg21.link/p0286r0
[P0443R13]
Jared Hoberock, Michael Garland, Chris Kohlhoff, Chris Mysen, Carter Edwards, Gordon Brown, D. S. Hollman, Lee Howes, Kirk Shoop, Lewis Baker, Eric Niebler. A Unified Executors Proposal for C++. 2 March 2020. URL: https://wg21.link/p0443r13
[P0581R1]
Marshall Clow, Beman Dawes, Gabriel Dos Reis, Stephan T. Lavavej, Billy O’Neal, Bjarne Stroustrup, Jonathan Wakely. Standard Library Modules. 11 February 2018. URL: https://wg21.link/p0581r1
[P0592R4]
Ville Voutilainen. To boldly suggest an overall plan for C++23. 25 November 2019. URL: https://wg21.link/p0592r4
[P0829R4]
Ben Craig. Freestanding Proposal. 12 January 2019. URL: https://wg21.link/p0829r4
[P0975R0]
Gor Nishanov. Impact of coroutines on current and upcoming library facilities. 10 March 2018. URL: https://wg21.link/p0975r0
[P1056R1]
Lewis Baker, Gor Nishanov. Add lazy coroutine (coroutine task) type. 7 October 2018. URL: https://wg21.link/p1056r1
[P1105R1]
Ben Craig, Ben Saks. Leaving no room for a lower-level language: A C++ Subset. 6 October 2018. URL: https://wg21.link/p1105r1
[P1171R0]
Lewis Baker. Synchronously waiting on asynchronous operations. 7 October 2018. URL: https://wg21.link/p1171r0
[P1212R0]
Ben Craig. Modules and Freestanding. 6 October 2018. URL: https://wg21.link/p1212r0
[P1288R0]
Lewis Baker. Coroutine concepts and metafunctions. 7 October 2018. URL: https://wg21.link/p1288r0
[P1316R0]
Lewis Baker. A when_all() operator for coroutines. 8 October 2018. URL: https://wg21.link/p1316r0
[P1341R0]
Lewis Baker. Unifying Asynchronous APIs in the Standard Library. 25 November 2018. URL: https://wg21.link/p1341r0
[P1371R2]
Sergei Murzin, Michael Park, David Sankel, Dan Sarginson. Pattern Matching. 13 January 2020. URL: https://wg21.link/p1371r2
[P1376R0]
Ben Craig. Summary of freestanding evening session discussions. 24 November 2018. URL: https://wg21.link/p1376r0
[P1453R0]
Bryce Adelstein Lelbach. Modularizing the Standard Library is a Reorganization Opportunity. 21 January 2019. URL: https://wg21.link/p1453r0
[P1502R1]
Richard Smith. Standard library header units for C++20. 15 August 2019. URL: https://wg21.link/p1502r1
[P1681R0]
Gor Nishanov. Revisiting allocator model for coroutine lazy/task/generator. 17 June 2019. URL: https://wg21.link/p1681r0