Trip report: Winter 2021 ISO C++ standards meeting (virtual)

Today, the ISO C++ committee held its second full-committee (plenary) meeting of the pandemic and adopted a few more features and improvements for draft C++23.

A record of 18 voting nations sent representatives to this meeting: Austria, Bulgaria, Canada, Czech Republic, Finland, France, Germany, Israel, Italy, Japan, Netherlands, Poland, Romania, Russia, Spain, Switzerland, United Kingdom, and United States. Japan had participated in person during C++98 and C++11, and has always given us good remote ballot feedback during C++14/17/20, and is attending again now; welcome back! Italy and Romania are our newest national bodies; welcome!

Our virtual 2021

We continue to have the same priorities and the same schedule we originally adopted for C++23. However, since the pandemic began, WG21 and its subgroups have had to meet all-virtually via Zoom, and we are not going to try to have a face-to-face meeting in 2021 (see What’s Next below). 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, over the past year we have held approximately 200 virtual meetings.

Today: A few more C++23 features adopted

Today we formally adopted a second round of small features for C++23, as well as a number of bug fixes. Below, I’ll list some of the more user-noticeable changes and credit all those paper authors, but note that this is far from an exhaustive list of important contributors… even for these papers, nothing gets done without help from a lot of people and unsung heroes, so thank you first to all of the people not named here who helped the authors move their proposals forward! And thank you to everyone who worked on the adopted issue resolutions and smaller papers I didn’t include in this list.

P1102 by Alex Christensen and JF Bastien is the main noticeable change we adopted for the core language itself. It’s just a tiny bit of cleanup, but one that I’m personally fond of: In C++23 we will be able to omit empty ( ) lambda parameter lists even when we have to declare the lambda mutable. I’m the one who proposed the lambda syntax we have today (except for the mutable part which wasn’t mine and I never liked), including that it enabled making unused parts of the syntax optional so that we can write simple lambdas simply. For example, today we can already write

[x]{ return f(x); }

as a legal synonym for

[x] () -> auto { return f(x); }

and omit the empty parameter list and deduced return type. Even so, I’ve noticed a lot of people write the ( ) part anyway, which isn’t wrong or anything, it’s just that often they write it because they don’t know they can omit it too. And part of the problem was the oddity in pre-C++23 that if you need to write mutable, then you actually do have to also write the ( ) (but not the return type), which was just weird but was another reason for people to just write ( ) all the time, because sometimes they had to. With P1102, we don’t have to. That’s more consistent. Thanks, Alex and JF!

In the spirit of “completing C++20,” P2259 by Tim Song makes several fixes to iterator_category to make it work better with ranges and adaptors. Here is an example of code that does not compile today for arcane reasons (see the paper), but will be legal C++23 thanks to Tim:

std::vector<int> vec = {42};
auto r = vec | std::views::transform([](int c) { return std::views::single(c);})
             | std::views::join
             | std::views::filter([](int c) { return c > 0; });
r.begin();

Further in the “completing C++20” spirit, P2017 by Barry Revzin fixes some additional glitches in ranges to make them work better. Here is an example of safe and efficient code that does not compile today, where for arcane reasons the declaration of e isn’t supported and today’s workaround is to make the code more complex and less efficient. This will be legal C++23 thanks to Barry:

auto trim(std::string const& s) {
    auto isalpha = [](unsigned char c){ return std::isalpha(c); };
    auto b = ranges::find_if(s, isalpha);
    auto e = ranges::find_if(s | views::reverse, isalpha).base();
    return subrange(b, e);
}

P2212 by Alexey Dmitriev and Howard Hinnant generalizes time_point::clock to allow for greater flexibility in the kinds of clocks it supports, including stateful clocks, external system clocks that don’t really have time_points, representing “time of day” as a distinct time_point, and more.

P2162 by Barry Revzin takes an important first step toward cleaning up std::visit and lay the groundwork for its further generalization. Even if you don’t yet love std::visit, it’s a useful tool that P2162 makes more useful by making it work more regularly. We expect to see further generalization in the future, which is much easier to do with a cleaner and more regular existing feature to build upon.

Finally, I saw cheers and celebratory emoji erupt in the Zoom chat window when we adopted P1682 by JeanHeyd Meneide. It’s very small, but very useful. When passing an enum to an API that uses the underlying type, today we have to write a static_cast to the std::underlying_type, which makes us repeat the enum’s name and so is cumbersome all the time and brittle for type-safety under maintenance if we change to use a different enum:

some_untyped_api( static_cast<std::underlying_type_t<ABCD>>(some_value) );

Thanks to JeanHeyd, in C++23 we will be able to write:

some_untyped_api( std::to_underlying(some_value) );

Note that of course standard library vendors don’t have to wait until 2023 to provide to_underlying or any of these other fixes and improvements. Just having a feature like this one voted into the draft standard is often enough for vendors to be proactive in providing it… these days, vendors are more closely tracking our draft standard meeting by meeting rather than waiting for the official release, in part because we are shipping regularly and predictably and we don’t vote features into the draft standard until we think they’re pretty well baked so that vendors have less risk in implementing them early.

We also adopted a number of other issue resolutions and small papers that made additional improvements.

Finally, we came close to adopting P0533 by Edward Rosten and Oliver Rosten, which is about adding constexpr to many of the functions in math.h that we share with C. This is clearly a Good Thing and therefore many voted in favor of adopting the paper. The only hesitation that stopped it from getting consensus this time were concerns that it needed more time to iron out how implementations would implement it, such as how to deal with errno in a constexpr context. This is the kind of question that often arises when we want to make improvements to entities declare in the C headers, because not only are they governed by the C standard rather than the C++ standard, but typically they are provided and controlled by the operating system vendor rather than by the C++ compiler/library writer, and those constraints always mean a bit of extra work when we want to make improvements for C++ programmers and remain compatible. As far as I know, everyone wants to see these functions made constexpr, so we expect to see this paper come to plenary again in the future. Thanks for your perseverance, Edward and Oliver!

What’s next

As long as we are meeting virtually, 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 two virtual plenaries to adopt features into the C++23 working draft will be held in June and November. Progress 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.

The next tentatively planned face-to-face meeting is February 2022 in Portland, OR, USA; however, we likely won’t know until well into the autumn whether we’ll be able to confirm that or need to postpone it. You can find a list of our meeting plans on the Upcoming Meetings page.

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.