Submitted by indi in programming

This is mostly a repost of a Reddit C++ post by Committee member Bryce Lelbach about the additions to C++20 in the most recent Committee meeting, with some edits and additional comments by me.


The following features were added to the C++20 draft:

The Parallelism Technical Specification Version 2 is now finalized and will be sent for publication. At the Jacksonville 2018 meeting earlier this year, we sent a draft out for national body balloting and feedback ("beta testing"). This week, we reviewed their feedback (53 individual comments) and finalized the TS.

The draft Reflection Technical Specification, which contains facilities for static reflection, has been sent out for national body balloting. This is the final step before publication. By the next meeting, we will have the results of the ballot; if all goes well, we will advance towards publication.

Language Evolution Working Group (EWG) Progress

EWG held an evening session to discuss concepts terse syntax. The Concepts TS has one form of terse syntax, but it was not merged into C++20 with the rest of the TS. There are two main proposals on how we might add an alternative design for terse syntax to C++20 under consideration:

A future proposal along these lines may use an "adjective" syntax, e.g. template void foo(Integral auto i).

We continued to work on evolving the Modules TS v1. The atom proposal was discussed, and we decided to merge its feature set with the feature set of the Modules TS v1.

EWG looked at a slew of constexpr-related papers, expanding what can be done in constant evaluation context, unifying various syntaxes, and realizing that constexpr function parameters are akin to non-type templates. Most of these papers got a positive reception and are expected to be discussed further.

Finally, we continued work on coroutines. This week, we discussed the core coroutines proposal, which suggests a different design than the Coroutines TS v1. The committee has decided to continue discussing coroutines at future meetings and there is still a desire to try and land the feature for C++20.

Library Evolution Working Group (LEWG) Progress

Library Evolution spent a lot of time this week preparing the Ranges TS for a merge into C++20. The standard library core concepts from the Ranges TS have now been voted into C++20. We're making good progress on the rest of the Ranges TS, which will be merged at a later meeting.

LEWG also revisited a number of design questions on span, such as whether it is Regular and what its equality operator should do (we decided it shouldn't have one), whether it should have a signed or unsigned index type (it's still signed), and whether it should have an at member function (no).

We also discussed a proposed study group on data persistence and I/O; there seems to be interest in this subject area. Those involved are working on a mission statement and will continue work in between meetings.

Finally, we created a new standing document on standard library compatibility.

Concurrency and Parallelism Study Group (SG1) Progress

This week, SG1 worked on executors, the Parallelism TS v2, and C++20 concurrency and parallelism features.

The current executors proposal and related proposals (such as the proposed concepts for futures) were discussed in a joint session of Library Evolution and SG1. A lot of the discussion revolved around how the library interface of the feature might be simplified. At this point, it is more likely that executors will go into a Technical Specification than into C++20.

However, SG1 will hold an extraordinary meeting in September, jointly with LEWG, to advance executors, with the goal of finding a solution for C++20.

SG1 also advanced a number of proposals targeting C++20 to the Library Evolution and Library Wording groups:

Finally, SG1 moved a fix to atomic compare-and-exchange guaranteeing that most types with padding-bits can be compare-and-exchanged.

Compile Time Study Group (SG7) Progress

SG7's role on the committee has evolved as it has aged. First, it was the "reflection" study group. About a year ago, it was expanded into the "reflection and metaprogramming" study group.

At this meeting, we once again expanded the scope of SG7. Now, the study group will address any matter relating to compile time programming. This should help us pipeline and parallelize proposal processing better.

Undefined Behavior Study Group (SG12) Progress

The undefined behavior (UB) study group met this week. We adopted a policy that not all UB has to be preserved from one version of the standard to the other, which will be derived from this paper. In general, members agree that reducing the amount of UB is good.

However, when changing UB the policy requests that authors do sufficient research to demonstrate how implementations diverge. For example, when changing the order of evaluation of parameters, we surveyed various compilers to see which would have to change their implementation and what impact this has, including on performance.

Tooling Study Group (SG15) Progress

The tooling study group, SG15, met for the second time this week to discuss package management in C++. We had representatives from most of the major C++ package managers in attendance as well as two papers on the subject:

This work is still very young, and SG15 will continue to hold sessions on the subject at future committee meetings.

Unicode Study Group (SG16) Progress

SG16 didn't meet this week, but will be meeting in San Diego. The only change was to update Unicode references, which sets the stage for the upcoming SG16 Unicode work.

Evening Session on 2D Graphics

We held an evening session to discuss the future of the the 2D graphics proposal. There was a proposal for continuing work on standardizing graphics and a proposal to stop working on graphics at this time.

After the discussion, there was no consensus to continue work on 2D graphics in the C++ International Standard at this time; perhaps we'll revisit the idea a few years down the road. However, the proposed library and specification may continue to be developed outside of the ISO C++ committee.

Proposed C++20 Release Schedule

We've scheduled three additional meetings between now and the next full committee meeting to work on specific parts of C++20.

NOTE: This is a plan, not a promise. Treat it as speculative and tentative.

  • IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.
  • TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.
  • CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").
      Meeting                               Location        Objective

DONE  2017 Spring Meeting                   Kona            C++17 completed.
DONE  2017 Summer Meeting                   Toronto         First meeting of C++20.
DONE  2017 Fall Meeting                     Albuquerque     Design major C++20 features.
DONE  2018 Spring Meeting                   Jacksonville    Design major C++20 features.
      2018 Summer Meeting                   Rapperswil      Design major C++20 features.
NEXT  2018 Summer LWG Meeting               Chicago         Work on wording for C++20 features.
NEXT  2018 Fall EWG Modules Meeting         Seattle         Design modules for C++20.
NEXT  2018 Fall LEWG/SG1 Executors Meeting  Seattle         Design executors for C++20.
      2018 Winter Meeting                   San Diego       Major language feature freeze.
      2019 Spring Meeting                   Kona            Feature freeze. C++20 design is feature-complete.
      2019 Summer Meeting                   Cologne         Complete CD wording. Start CD balloting ("beta testing").
      2019 Fall Meeting                     Belfast         CD ballot comment resolution ("bug fixes").
      2020 Spring Meeting                                   CD ballot comment resolution ("bug fixes"), C++20 completed.
      2020 Summer Meeting                                   First meeting of C++23.

Status of Major Feature Development

NOTE: This is a plan, not a promise. Treat it as speculative and tentative.

  • IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.
  • TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.
  • CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").
Feature     Status                                                      Depends On  Current Target              Current Target
                                                                                    (Conservative Estimate)     (Optimistic Estimate)

Concepts    Concepts TS v1 published and merged into C++20                          C++20                       C++20
http://en.cppreference.com/w/cpp/language/constraints

Ranges      Ranges TS v1 published; core concepts merged into C++20     Concepts    C++20                       C++20
http://en.cppreference.com/w/cpp/experimental/ranges

Contracts   Merged into C++20                                                       C++20                       C++20
https://wg21.link/P0542

Modules     Modules TS v1 published                                                 TS v2 in C++20 timeframe    C++20
https://wg21.link/P0678                                                             and IS in C++23

Coroutines  Coroutines TS v1 published                                              C++23                       C++20
https://wg21.link/N4723

Executors   Proposal                                                                TS in C++20 timeframe       C++20
https://wg21.link/P0761                                                             and IS in C++23

Networking  Networking TS v1 published                                  Executors   C++23                       C++20
https://wg21.link/N4711

Futures     Proposal                                                    Executors   TS in C++23 timeframe       TS in C++20 timeframe
https://wg21.link/P1054                                                             and IS in C++26             and IS in C++23

Reflection  Draft Reflection TS v1 sent for ballot                                  TS in C++20 timeframe       TS in C++20 timeframe
https://wg21.link/P0194                                                             and IS in C++26             and IS in C++23

So C++20 will have Concepts, Contracts, and probably Ranges. This is along with previously approved additions like span, the "spaceship operator" (<=>), a proper date/time library (based on <chrono>), more futures and concurrency stuff, and so on.

The one missing feature that everyone really wants to get into C++20 is Modules. The most important missing feature is probably Executors, because a whole bunch of other stuff depends on Executors: Networking, Futures, more Parallelism stuff, heterogenous computing (that is, running programs on the GPU).

There are meetings scheduled in the fall specifically for Modules and Executors, in the hopes that they might still make it into C++20.

We've lost Graphics, unfortunately. That was a huge blow. Consensus seems to be that before anything as grandiose as Graphics is attempted again, there should first be some kind of standardized package/dependency management for C++. If we had proper package/dependency management, the reasoning goes, third party graphics libraries could suffice - and maybe in a few years, if one stands out, that might be a candidate for standardization.

5

Comments

You must log in or register to comment.

jhasse wrote

We've lost Graphics, unfortunately.

I think that's a good thing. Coroutines and Networking is far more important IMHO.

1

indi OP wrote

Sure those things are good, and arguably more generally useful than a standard graphics API... but the whole point of the TS system is that things can be developed independently of each other, in parallel. Work on the Graphics TS was being done by SG13 completely independently of Networking in SG4 and any other study group like SG6 (Numerics) or SG16 (Unicode).

In fact, the Graphics API was basically finished, and running - with demos and even supporting tooling. And it's not like the human interface experts from SG13 will migrate over to Networking or Coroutines now that SG13 is shut down. So nothing has really been gained by cancelling Graphics... just a lot of time wasted.

What really killed Graphics was SG15, and the new focus on developing a standard package/dependency management system. One can hope that if that actually happens, the standard can be modularized, which would make it much easier to add bigger things to the standard. At that point, Graphics can probably be revived.

1