Report from July 2019 ISO C++ Meeting (Core Language)

The summer 2019 C++ meeting was in Cologne, Germany, 10 years since our last meeting in Germany. As usual, Red Hat sent three of us to the meeting: I attended in the Core language working group (CWG), Jonathan Wakely in Library (LWG), and Thomas Rodgers in SG1 (parallelism and concurrency).

At the end of the meeting, as planned, we voted to send out a draft of the C++20 standard for comments from the national bodies. The most surprising thing about it was the proposal to:

The disagreements from the February meeting in Kona continued at this meeting; since no consensus seemed likely during the week, the two sides agreed to remove the Contracts feature from C++20 and revisit it for the next standard. A new Study Group was formed for continuing discussion, to be led by a neutral party.

Other than that, the contents of the draft were about as expected. Quite a few minor features and corrections that had previously been approved by Evolution made it through Core and into the draft at this meeting:

Everything you need to grow your career. With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development. SIGN UP

Concepts

This clarifies the semantics of overloaded of constructors and destructors with different constraints, for example:

struct empty {}; template <typename T> class optional { bool engaged = false; union { empty _ = {}; T value; }; public: constexpr optional() = default; // non-trivial due to default member initializer constexpr optional(optional const&) requires std::is_trivially_copy_constructible_v<T> = default; constexpr optional(optional const& o): engaged(o.engaged) { if (o.engaged) new (&value) T(o.value); } ~optional() requires std::is_trivially_destructible_v<T> = default; ~optional() { if (engaged) value.~T(); } // ... };

If the requirements of the first overload of the copy constructor or destructor are satisfied, it effectively hides the second overload which is less constrained, so optional<int> is trivially copy-constructible and trivially destructible.

Normally, a template template parameter (TTP) must be at least as specialized as its template template argument. However, that meant that there was no way to write a TTP that accepted any template regardless of its constraints:

template <template <typename> typename TT> struct A {}; template <typename T> concept Any = true; template <Any> struct B; A<B> a; // previously error (TT is less constrained than B), now OK

As I pointed out during discussion of this paper, there is already an exception for a TTP with a template parameter pack accepting an argument template with a specific number of template parameters; this adds the parallel escape hatch for constraints, so that a TTP with no constraints at all will match a constrained argument template.

For a compound-requirement in a requires-expression, it was found unclear whether

{ expr } -> Type

ought to require the exact type or convertibility. So, use of a type here was removed for C++20, and users can choose for themselves with

{ expr } -> Same<Type>

or

{ expr } -> ConvertibleTo<Type>

Modules

First, structs with only typedef names for linkage purposes, for example:

typedef struct { int i; } foobar;

have always been fragile if any of their members are affected by that linkage, e.g. member functions or static data members, and we finally made such members ill-formed. Because this is a C compatibility hack, limiting it to definitions that can actually appear in C seems reasonable.

Second, it is now ill-formed (no diagnostic required) for a function to have different default arguments in different translation units.

Allows a single definition of an entity in a translation unit even if a definition is also available from an imported module, to reduce headaches from multiple inclusion of legacy header files.

Requires that a header unit import declaration be on a line by itself, starting with import or export import , for easier partial preprocessing.

Spaceship (operator<=>)

Allows synthesis of operator<=> from operator< and operator== if an explicit return type is provided.

Clarification of comparison operator synthesis and how rewritten comparison operators participate in overload resolution.

constexpr

In C++17, a variable in a constexpr function must be initialized. This paper removes that requirement and replaces it with a requirement that an object must be given a value before it is read from. So,

constexpr int f(int i) { int j; // error in C++17, OK in C++20 j = i; // j now has a value return j; // OK } constexpr int x = f(42); // OK constexpr int g(int i) { int j; // error in C++17, OK in C++20 return j; // ill-formed, no diagnostic required: will never produce a constant value } constexpr int y = g(42); // error, non-constant initializer

Another thing that’s no longer prohibited in a constexpr function; it just doesn’t produce a constant value.

A new keyword to require constant (static) initialization of a non-const variable:

constexpr int f(int x) { return x; } constinit int i = f(42); // OK constinit int j = f(i); // error, i isn't constant

Allowing containers such as std::vector to be used in constexpr functions, by requiring that allocation/deallocation pairs be omitted during constant evaluation (as has been permitted in dynamically evaluated code since C++14).

Filling in missing functionality for [[nodiscard]] .

Supporting CTAD for additional templates. There was also a proposal to support deduction from inherited constructors, but the wording wasn’t ready in time.

Allowing a user to import the enumerators of a scoped enumeration into the current scope, so they can be named without explicit scope.

enum class A { a1 }; using enum A; int i = a1;

Note that there is significant bikeshedding happening on the lists at the moment, so the syntax may change before the final C++20 standard.

Permitting conversion from array of known bound to array of unknown bound in pointer conversion and reference binding.

int arr[42]; void f(int(&)[]); void g(int(*)[]); f(arr); // now OK g(&arr); // now OK

Loosens the C++11 conditions for implicit move in throw or return in various ways: now rvalue references will also be implicitly moved from, and implicit move is not limited to a constructor taking an rvalue reference to the returned expression’s type.

struct Movable { Movable(Movable&&); }; Movable f1(Movable &&r) { return r; } // now moves struct Derived: Movable { }; Movable f2(Derived d) { return d; } // now moves struct Proxy { Proxy(Movable); }; Proxy f3(Movable m) { return m; } // now moves

Expressions such as ++ or += that involve both load and store of a volatile lvalue are deprecated, as are volatile-qualified parameter and return types.

The authors would like to be able to use the comma in an array subscript to separate multiple arguments to operator[] rather than as the comma operator, so the existing semantics are deprecated in C++20 to make room for new semantics in a future standard.

array[x,y] // Deprecated, uses y as index/key

A fairly subtle adjustment to consume semantics to make them less broken on ARM. Most implementations treat consume as acquire, so this will not affect users.

The next meeting will be in Belfast, Northern Ireland in November, where we will start to process national body comments on the C++20 draft. If you have any comments, please send them to a committee member to pass along.