A few minutes ago, the ISO C++ committee completed its fall meeting in Albuquerque, New Mexico, USA, hosted with our thanks by Sandia National Laboratories. We had some 140 people at the meeting, representing 10 national bodies. As usual, we met for six days Monday through Saturday, including several evenings.
The following are some highlights of what we achieved this week. You can find a brief summary of ISO procedures here. The main things to note are:
- “IS” means “international standard.” In our case, it’s the core C++ standard itself. Think of this as “trunk.”
- “TS” means “technical specification,” a document separate from the main standard where we can gain experience with new features before putting them into the IS. We have several of these, summarized on the status page. Think of these as “beta branches.”
Modules TS ballot comments: Almost done
A primary goal of the meeting was to address the comments received from national bodies in the Modules TS’s comment ballot that ran this summer. We managed to address them all in one meeting, as well as deal with most of the specification wording issues discovered in the process of responding to the national comments; we discovered one or two areas where the TS wording did not quite match the approved design intent, and so the plan is to finish addressing those and to approve the Modules TS for publication in between meetings via a teleconference, rather than wait for our next face to face meeting in March.
It will be great to get the TS published, and continue getting experience with implementations now in progress, at various stages, in all of Visual C++, Clang, and gcc as we let the ink dry and hammer out some remaining design issues, before starting to consider adopting modules into the C++ draft standard itself. I do not know whether modules will make the feature cutoff for C++20, but a lot of people are working hard to maximize the chances… we’ll know in another 12-18 months when we reach the C++20 feature cutoff.
Second meeting for C++20
This was also the second meeting where we could vote changes into Draft C++20. And we did!
Here are some of the features that were added to C++20 at this meeting. Note: These links currently find the most recent pre-meeting papers and so may not reflect the exact wording adopted at the meeting, but the links will light up to the post-meeting versions of the papers that were actually adopted as soon as those are available in the post-meeting mailing about three weeks from now.
Range-based for statements with initializer (Thomas Köppe). In C++17, we already allowed initialization of if-scoped and switch-scoped variables, just like the ordinary for loop has already had for years. Today, we added the same for the range-based for loop, which gives the same benefit: It enables and encourages locally scoped variables without the programmer having to introduce a scope manually. To take an example from the paper, in C++17 we might write the following to get a variable thing that exists just as long as is needed for the for loop, which avoids a bad pitfall (do you see why the “WRONG” comment is wrong? it might work depending on what f() returns, or it might be undefined behavior):
{
T thing = f();
for (auto& x : thing.items()) {
// Note: “for (auto& x : f().items())” is WRONG
mutate(&x);
log(x);
}
}
and now in draft C++20 we can write the recommended local scoping directly with less ceremony of { } and indenting, and follow the C++ Core Guidelines scoping recommendations now also for range-for, as just:
for (T thing = f(); auto& x : thing.items()) {
mutate(&x);
log(x);
}
Bit-casting object representations (JF Bastien). This proposal gives a way to copy the bits of an object in a consistent and simple manner. It adds the new header <bit>, and provides bit_cast for trivially-copyable “bag-o-bits” objects, to easily copy the bits of any such object to another of the same size (the types need not be the same). Note: Yes, we already have memcpy, but bit_cast is safer and also can run at compile time.
Lots of other cleanup. We did various smaller features and cleanup, sometimes to fix bugs, sometimes to improve consistency and generality, and sometimes to make the language a little simpler to use.
- Example of bug fixes: Draft C++20 sets forth more precisely where constexpr functions are defined (core issue 1581).
- Examples of consistency and generality: Draft C++20 now supports concepts requires-clauses in more places including lambdas (P0857, Thomas Köppe). Also, stateless (non-capturing) lambdas are now default constructible and assignable, which makes them more convenient to create and use (P0624, Louis Dionne).
Operator <=>, aka “spaceship” (myself). Beyond those, my personal favorite is that the committee adopted my own proposal for the <=> “spaceship” three-way comparison operator (language wording; library wording). Many thanks to all the proposal’s reviewers, including all the authors of previous proposals in this area and especially Jens Maurer and Walter Brown for standardese wording help. This will greatly simplify how to write comparisons.
For example, in C++17 if we want to have a case-insensitive string type CIString that supports comparisons between two CIStrings and between a CIString and a C-style char* string, we would have to write something like the following 18 nonmember friend functions:
class CIString {
string s;
public:
// ...
friend bool operator==(const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) != 0; }
friend bool operator< (const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) < 0; }
friend bool operator!=(const CIString& a, const CIString& b) { return !(a == b); }
friend bool operator> (const CIString& a, const CIString& b) { return b < a; }
friend bool operator>=(const CIString& a, const CIString& b) { return !(a < b); }
friend bool operator<=(const CIString& a, const CIString& b) { return !(b < a); }
friend bool operator==(const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) != 0; }
friend bool operator< (const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) < 0; }
friend bool operator!=(const CIString& a, const char* b) { return !(a == b); }
friend bool operator> (const CIString& a, const char* b) { return b < a; }
friend bool operator>=(const CIString& a, const char* b) { return !(a < b); }
friend bool operator<=(const CIString& a, const char* b) { return !(b < a); }
friend bool operator==(const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) != 0; }
friend bool operator< (const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) < 0; }
friend bool operator!=(const char* a, const CIString& b) { return !(a == b); }
friend bool operator> (const char* a, const CIString& b) { return b < a; }
friend bool operator>=(const char* a, const CIString& b) { return !(a < b); }
friend bool operator<=(const char* a, const CIString& b) { return !(b < a); }
};
With this proposal, the class’s comparisons could instead be implemented as just two ordinary member functions (vs. the 18 that had to be nonmember friends above):
class CIString {
string s;
public:
// ...
std::weak_ordering operator<=>(const CIString& b) const
{ return ci_compare(s.c_str(), b.s.c_str()); }
std::weak_ordering operator<=>(const char* b) const
{ return ci_compare(s.c_str(), b); }
};
and objects of this type can still be used just as flexibly and efficiently as if the class author had written all of the above two-way operators in the first version, because now the compiler will rewrite expressions like s1<s2 to (s1<=>s2 < 0) for you automatically. Additionally, unlike the first attempt, this version also documents in code that the kind of ordering being returned is a weak ordering, not a strong (total) ordering. I’m a fan of writing less code to say more, and to say it more accurately. Please see the paper linked above for more details.
In related news, at this meeting the Library Evolution subgroup also began considering David Stone’s proposal to apply operator<=> to the standard library, and it got a warm reception and is expected to progress over the coming meetings. If it succeeds, we hope it may possibly let us get a small reduction in the size of the standard library specification as well as a result. Additionally, at this meeting we discovered that having <=> opens an unanticipated door for language evolution: Because the default operator<=> is guaranteed to be memberwise, so that we can know those are its semantics at compile time, a brand-new proposal by Jeff Snyder can leverage it to solve the remaining problems that before prevented us from using non-built-in types as non-type template parameters; we’ll see more of his proposal at our next meeting. That’s a good sign of a feature that is generally useful in the language beyond just its intended use cases.
We also approved extensions to the standard library:
atomic<shared_ptr<T>> (myself, Alisdair Meredith): This was originally my proposal and I got it into the Concurrency TS; many thanks to Alisdair Meredith who got it the rest of the way into draft C++20 over the past two meetings. There are changes since it appeared in the Concurrency TS, including to make it use the name I originally proposed (and not “atomic_shared_ptr<T>”).
Here’s more that we got at this meeting on the standard library side. If you notice “constexpr” being mentioned a few times above already, and some more below, that’s no accident; in Library subgroup chair Marshall Clow’s words, “the future of constexpr is bright.” The following other progress also includes more work on enabling features to work at compile time, including most of the rest of the standard algorithms:
- The draft Parallelism TS 2 got a template library for parallel for loops (Pablo Halpern, Clark Nelson).
- Draft C++20 got remove_cvref (Walter E. Brown)…
- and the [[nodiscard]] attribute in the standard library (Nicolai Josuttis)…
- and synchronized buffered ostreams (Lawrence Crowl, Peter Sommerlad, Nicolai Josuttis, Pablo Halpern)…
- and more of the standard <algorithm> and <utilities> features being constexpr (Antony Polukhin)…
- and constexpr std::complex (Antony Polukhin)…
- and atomic<floating point type> (H. Carter Edwards, Hans Boehm, Olivier Giroux, JF Bastien, James Reus)…
- and starts_with and ends_with for std::string and std::string_view (Mikhail Maltsev).
(Aside: At this meeting, the Evolution subgroup also provisionally allowed constexpr (compile-time) new, vector, and string. Stop a moment, and think about what that means. — That is not yet in C++20, but it’s on its way and could be approved for draft C++20 in another few meetings… and if this all reminds you of the CppCon “constexpr all the things!” talk title, you’re exactly right.)
And much more. Thanks to all those proposal authors and the issues list proposed wording contributors and all their helpers, without which this team effort would not succeed meeting after meeting. None of the proposers could get it done without all the contributions of many people who work tirelessly all the way from design feedback to detailed wording review, usually for no public glory, and we appreciate their indispensable help. For any of the above papers you happen to have interest to click on, please be sure to look also at the Acknowledgments section, many of which are quite extensive and deservedly so.
We also continued incubating other work. In particular, the Reflection study group had presentations, and gave direction and feedback, on static reflection for functions, as well as design feedback on Section 5 of my metaclasses paper. The Undefined/Unspecified Behavior study group met for two days with our sister committee WG23 (Vulnerabilities) co-located at the same venue to start work on a C++-specific document about programming language vulnerabilities and guidance, in conjunction with (and already providing new feedback for) the C++ Core Guidelines.
What’s next
Here’s an updated snapshot of our status:
Thank you again to the 140 experts in Albuquerque this week, and the many more who participate in standardization through their national bodies! Have a good winter… we look forward now to our next meetings in March (Jacksonville, Florida, USA) and June (Rapperswil, Switzerland).
[This post will be updated with additional details as mentioned in the comments section at bottom.]
Sutter’s Mill 