On Monday, the ISO C++ committee completed its final full-committee (plenary) meeting of 2020 and adopted the first changes to the C++23 working draft, including a few new features.
This was a first in several ways: It was our first-ever virtual plenary, held online via Zoom. It was also our first-ever plenary meeting that wasn’t held at the end of a long around-the-clock week of intensive subgroup meetings; instead, it was held at the end of nearly nine months of virtual subgroup meetings.
Our virtual 2020
The pandemic was just getting started when we held our February meeting in Prague, Czech Republic. Since then it has of course been impossible to meet in person; as I mentioned before, our ISO C++ meetings are virtual until further notice, but we continue to have the same priorities and the same schedule for C++23.
So since the pandemic began, WG21 subgroups have been meeting virtually via Zoom. Some subgroups had already been having virtual meetings for years, but this was a major change for other groups including our two main design groups – the language and library evolution working groups (EWG and LEWG).
In all, since Prague we have held about 150 virtual meetings. When lots of subgroups are meeting, some of them weekly, those meetings add up!
This week: First C++23 features adopted
On Monday we formally adopted the first features of C++23, including the first C++23 language feature, as well as a number of bug fixes.
First up was P0330 by JeanHeyd Meneide, which adds a literal suffix for (signed) size_t, so in C++23 we will be able to write literals like 100uz. (I wonder whether uz will be pronounced Uzi.) See the many excellent side-by-side examples in JeanHeyd’s paper for how this helps make uses of size_t safer and more convenient especially in naked for loops iterating over containers. Congratulations to JeanHeyd for C++23’s first language extension, and also for his persistence with this paper – the adopted version is revision 8, and that number and the paper’s change history indicates the level of rigor that can be required to get a feature into C++. Many thanks!
P1679 by Wim Leflere and Paul Fee add a basic_string::contains function so we can write code like if (str.contains(substr)) std::cout << “found!\n”; … I can already hear the chorus of “finally!”
P0881 by Alexey Gorgurov and Antony Polukhin add a stacktrace library to C++23. This is a much-anticipated extension based on Boost.Stacktrace that will enable much easier-to-debug portable diagnostic messages.
The charmingly numbered P1048 by Juan Alday gives us an is_scoped_enum type trait to detect when an enumeration is defined using the new-style (C++11, but well it’s still “new”!) enum class. As the paper points out, this is particularly useful as a migration aid, including to write code that detects and measures the adoption of “enum class” over plain old “enum.”
Finally, P0943 by Hans Boehm supports C atomics (spelled _Atomic) in C++ where the two did not already overlap, which helps write headers that work in both C and C++. (The adopted version is R6 which should be published in the next few weeks.) This is one example of the ongoing extra coordination we’ve had lately between the C and C++ committees, which leads to the next thing we did…
New SG22: C/C++ liaison
We appointed a new study group, SG22, for C/C++ liaison. This is a unique study group, because it is shared jointly by both the C and C++ committees, and it continues the tradition of closer coordination between the two committees. Thank you to WG14 (C) and its chair David Keaton for their continued interest in coordinating the two languages, to Aaron Ballman for agreeing to chair this new group, and for our WG14 and WG21 project editors Thomas Köppe, JeanHeyd Meneide, and Richard Smith to serve as assistant chairs. Thank you all for being willing to step up!
Other updates
Thank you to Richard Smith for his work for many years as project editor for the C++ standard, and completing C++20 this month! Thank you also to the many of you who have helped Richard and shared the editing workload by providing PRs and proofreading to apply plenary resolutions; that has been very much appreciated by Richard and by all of us especially given that C++20 is a “big” release with many new features, all of which have created an unusually high amount of editing work for this release.
Starting now, as we begin C++23, Thomas Köppe has graciously agreed to step up to be our primary project editor for the standard, with Richard as backup project editor. Thank you Thomas, and thank you again Richard and to all who have helped with the editing for the C++ IS!
Next steps
While we are meeting virtually until further notice, we will continue to have virtual plenaries like the one we had this week to formally adopt new features as they progress through subgroups. Our next virtual plenary will be in February, on the Monday of what would have been the Kona meeting.
Progress during this time will be slower than when we can meet face-to-face, and we’ll doubtless defer some topics that really need in-person discussion until we can meet again safely, but in the meantime we’ll make what progress we can and we’ll ship C++23 on time.
Thank you again to the hundreds of people who are working tirelessly on C++, even in our current altered world. Your flexibility and willingness to adjust are much appreciated by all of us in the committee and by all the C++ communities! Thank you, and see you on Zoom.
Sutter’s Mill 
Any news on the pattern matching proposal? I’ve seen conflicting reports on if it’s expected to be included in C++23.
@Wim
> Namely that a free function is ambiguous, is it contains(string, substring) or contains(substring, string)?
Granted, but there are already algorithms like find_end and search that do just that.
Contains would just return a bool instead of an iterator, which is why I doubt the need for it.
> Contains for collections is usually to check if an element exists. While for a string it’s a substring check.
That is at most a naming issue. has_subsequence should be clear enough.
But as there are already algorithms that can do the job, I think it is unnecessary.
Instead of two versions of the same algorithm there should be an algorithm adaptor,
that takes an algorithm and a range, and returns a boolean by comparing the return value to the end of range.
It could be used with multiple algorithms that may return the end iterator.
The reason for adding contains as a string member function is explained in the paper.
Namely that a free function is ambiguous, is it contains(string, substring) or contains(substring, string)?
Adding it as a generic contains function would be ambiguous too.
Contains for collections is usually to check if an element exists.
While for a string it’s a substring check.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1679r3.html#42-member-function-vs-free-function
Still no way to reflect on enum… disaster…
I really do hope reflection gets into C++23 so we can get that…
I recently had to deal with some old code that I could have made much nicer if I had a way to check on enum values during compiletime…
And contains is only 25 years too late, but at least sanity prevailed and hate for member functions in WG21 is declining…
> P1679 by Wim Leflere and Paul Fee add a basic_string::contains function so we can write code like if (str.contains(substr)) std::cout << “found!\n”; … I can already hear the chorus of “finally!”
There may be demand for a contains algorithm, but I think the basic_string is a wrong place for it.
Rather it should be a standard algorithm so it can be used with any range.