A few minutes ago, the ISO C++ committee completed its final meeting of C++20 in Prague, Czech Republic. Our host, Avast Software, arranged for spacious and high-quality facilities for our six-day meeting from Monday through Saturday. The extra space was welcome, because we had a new record of 252 attendees. We currently have 23 active subgroups, and met in nine parallel tracks all week long; some groups ran all week, and others ran for a few days or a part of a day, depending on their workloads.
See also the Reddit trip report, which was collaboratively edited by many committee members and has lots of excellent detail. You can find a brief summary of ISO procedures here.
C++20 is done!
Per our published C++20 schedule, we finished technical work on C++20 at this meeting. No features were added or removed, we just handled fit-and-finish issues including addressing all of the 378 national body comments we received in last summer’s international comment ballot (Committee Draft, or CD). The next step is that the final document will be sent out for its international approval ballot (Draft International Standard, or DIS) and will be published later this year.
In addition to C++20 work, we also had time to make progress on a number of post-C++20 proposals, including continued work on contracts, networking, executors, reflection, compile-time programming, pattern matching, and much more. We also discussed ABI stability and took polls that said we are definitely not willing to guarantee pure ABI stability forever, and we are ready to consider proposals (especially ones that enable performance improvements) even if they may require an ABI break or migration on some platforms for affected types and functions, but that we aren’t ready to take a broad ABI break across the entire standard library. This is an important and meaningful decision, and an engraved invitation for proposal authors to bring proposals (and to bring back previously rejected ones) for their “wish lists” of such potentially-affected features, as soon as our next meeting this June. I’m looking forward very much to seeing how this can spur further C++ standard library innovation for C++23.
Speaking of C++23…
C++23 schedule and priorities
For the first time, we formally adopted a schedule and a planned set of feature priorities for the next round of standardization, C++23, right at its outset.
The schedule for C++23 reaffirms that we’ll use the same meeting and feature-freeze deadline schedule that we used for C++20. Note that this means we are “only” two years away from the feature freeze of the next standard! Two years has a way of going by really quickly – “warning: objects in the schedule are closer than they appear.”
The priorities for C++23’s feature set are to focus our work on the following, emphasizing upgrades to the standard library:
- “Finishing C++20” with standard library modules and library support for coroutines. This will let programmers use the standard library via modules, and easily use coroutines with futures and other common types right “out of the box” (today some additional coding or a helper library is required).
- Adding executors and the networking library that relies on executors.
On the language side, we will prioritize progressing the following as quickly as possible, for C++23 “if possible” but we’ll know better in a year or two whether they are likely to make it for 23 or not:
- Reflection, including introspection to query the program, compile-time programming to manipulate the results, and generation to inject new entities into the program.[1]
- Pattern matching, which also progressed at this meeting with continued feedback on proposals.
- Contracts, which we spent another half-day on in SG21 on Friday afternoon.
As a second priority, the wording groups will also prioritize bug fixing higher than in the past, to pay down technical debt faster.
There will also be plenty of work on other features, so do expect C++23 to contain other work too. The purpose of setting these priorities is to mainly to say that at any given meeting we are not going to spend a lot of time working on other proposals until we have made as much progress as possible on the above ones first, that’s all. This way at each meeting we will give these proposals’ authors the maximum help and direction we can, so they can get as much further work done in the gap until the next meeting.
Finally, note that “priorities” doesn’t mean “commitments.” Prioritizing these features is not a commitment that they’ll all be done in time for C++23, though we hope that most of them may likely be. Watch the next two years’ trip reports and you’ll get a good sense of how we’re making progress against these priorities.
Wrapping up
Thank you again to the 252 experts who attended this final meeting of C++20, and the many more who participate in standardization through their national bodies!
But we’re not slowing down… in less than four months we’ll be meeting again in Varna, Bulgaria, for the first meeting to start adopting features for C++23. I look forward to seeing many of you there. Thank you again to them and to everyone reading this for your interest and support for C++ and its standardization.
Notes
[1] For those who are interested in my metaclasses proposal, this is ~98% of metaclasses – as soon as this reflection work lands, the only thing that will be left for me to propose to complete metaclasses is to add a declaration syntax like class(M) as “just” a minor syntactic sugar for invoking a consteval function that takes a meta::info reflection of the class body as input.
Sutter’s Mill 
Herb I recently listened to your Feb. webcast at the Winter ISO C++ standards meeting (Prague) on C++ complexity and resulting C++ use/learning issues. I thought it was an excellent presentation. And your profiling various C++ features and your complexity ranking was very interesting and appears promising. But it would seem the complexity of function parameter passing/returning and related concepts can be most understandably presented by discussing the ByRef and ByVal methods for int(s), doubles, classes, functions, etc. It would seem that abstraction should not hide the problem being addressed, but help prevent errors and guide developers to more efficiently and correctly code. C++’s “close to hardware” focus in the evolving parallel processor era makes C++ essential for many more applications and programmers. Thank you.
I for one am very grateful that the Circle proposal was not adopted by the committee. Personally, I found the Circle proposal to be interesting, but overall unconvincing as a replacement for the current reflection proposal. Looked at from the perspective of reflection, it combines reflection and reification, making it impossible to store a reflection value. Which means you can’t do obvious things like pass around collections of reflection values. It tries to sidestep this limitation in part by building its own macro system (meaning that C++ would now have 3 separate “macro” systems: C preprocessor, templates, and Circle macros). But that’s just another can of worms; C++ needs another macro language like it needs a hole in the head.
When I evaluate reflection proposals, I try to look at my most common use case for reflection: automatic marshaling of values between languages. That is, I want to be able to call a function which takes a C++ function with a specific signature, and this function generates an object which can convert a function call from a scripting language into a call to that C++ function.
The current reflection direction (including all relevant proposals, like constexpr parameters, tuple-like object expansions, etc) generates code that makes sense to me. You analyze the function’s parameters, which results in a vector of reflection values. When you invoke the marshaling routine, for each reflection value, you ask call a function that extracts the parameter from the scripting language, based on the reflection value for that parameter. The return value is marshaled similarly. The code for the current reflection direction looks very much like this general algorithm.
I don’t understand what the equivalent Circle code would even look like.
And from a personal perspective, I found the arguments in the Circle paper to be quite unconvincing. Particularly the notion that constexpr code was somehow impenetrable or non-C++ like, even though it is just regular C++ code. Ignoring the irony of making that claim while proposing another C++ macro-like language that itself is un-C++-like, all of the individual components needed to make constexpr code usable for reflection also have other uses. Being able to iterate over a tuple for example is necessary for doing reflection/reification tasks, but it’s a basic tool that would be of great value in tons of places that have nothing to do with reflection. Constexpr function parameters are essential for reflection, but they also make it possible to apply `operator[]` to types like `std::tuple`. Constexpr containers are again necessary to make reflection work, but they have tons of other uses too.
In short, we want all of those features *anyway*, whether Circle exists or not.
Circle feels like this top-down, all-in-one design that’s a lot more like C++0x concepts. The current direction of reflection and constexpr programming feels more like building a bunch of tools, each tool having a legitimate purpose, but also furthering the overall goal of achieving reflection/reification. Top-down design is nice to some degree, but it’s incredibly fragile, as we saw with C++0x concepts.
It’s not so much that I think Circle is bad. It’s more that it’s not actually *better*, despite what the writers of the proposal feel. I don’t feel that the concerns they have with the current direction are valid (or at least not well argued in their proposal), and I *really* don’t like what it turns reflection/reification style code into.
And I really don’t feel that “questions” about whether Circle was rejected for good cause are justified; that sounds a bit like spreading FUD. There was a whole paper arguing against Circle and in favor of the current direction. You may disagree with those arguments, but I don’t think it’s fair to act as though those arguments are just a thin justification for a conservative “let’s keep doing what we’re doing no matter what” attitude.
Was their nothing learned and taken from the Circle proposal?
Is their nothing being done to mitigate the legitimate concerns that the current direction is turning into an expert only language feature with near comparable complexity of the existing template features?
I am hoping the elegant simplicity wasn’t discarded primarily based on the gargantuan work effort already put into the current direction. That would be a bad precedent for the standardization process in general. Failing to serious embrace an opposing camp could result in failure of adoption along the lines of concepts >7 years ago and these reflection capabilities are desperately needed now.
Rather I was hoping that previous decisions made, that led to the current direction, would be re-evaluated leading to more easily implemented current design. Some of these decisions from earlier meetings that affected the current design may have been made with not enough people in the room. General users of reflection may be more in favor of a textual C++ representation being compiled since it would support both present and future syntaxes rather than a constexpr codedom that would need to grow and keep growing to express everything in the C++ language. Would a general user need to know abstract syntax trees, GVALUES and PVALUES or just plain old C++, code language syntax!
Thanks for the response above !
As to Daveed’s paper, i was actually referring to P0596[1]. Was curious to know if it affected the Reflection direction in any way.
[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0596r1.pdf
@Dusan: I totally understand, and I take it as a personal challenge to try to eventually make a believer out of you :) … “eventually” as this a multi-year journey and I understand that timescale is too long for many people.
@Patrick: In Prague we affirmed to continue on the previous converged direction, in particular not to pursue the Circle-like model. That was Daveed’s only paper in the pre-Prague mailing. Expect more updates in about two months in the pre-Varna mailing (early May)…
Herb can you please comment on the direction of reflection feature whether its to build on the “compromised” dual version monotype/multi-type or if SG7are still considering other direction?
Also how was daveed’s compile time side effects paper was recieved?
Thank you, Herb. I am using C++ commercially since 1992. Let me just say here: The future of C++? I am not hopeful. “Remember the Vasa” …