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:
Remove Contracts from C++20
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:
Concepts
Conditionally trivial special member functions
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.
Unconstrained template template parameters and constrained templates
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 OKAs 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.
Removing return-type requirements
For a compound-requirement in a requires-expression, it was found unclear whether
{ expr } -> Type { expr } -> Same<Type> { expr } -> ConvertibleTo<Type>Modules
Mitigating minor modules maladies
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.
Relaxing re-export redefinition restrictions
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.
Recognizing header units
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<=>)
When do you actually use operator<=>?
Allows synthesis of operator<=> from operator< and operator== if an explicit return type is provided.
Spaceship needs a tune-up
Clarification of comparison operator synthesis and how rewritten comparison operators participate in overload resolution.
constexpr
Trivial default initialization in 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 initializerUnevaluated asm in constexpr functions
Another thing that's no longer prohibited in a constexpr function; it just doesn't produce a constant value.
Adding the constinit keyword
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 constantMore constexpr containers
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).
[[nodiscard("should have a reason")]]
[[nodiscard]] for constructors
Filling in missing functionality for [[nodiscard]].
Class template argument deduction (CTAD) for aggregates
CTAD for alias templates
Supporting CTAD for additional templates. There was also a proposal to support deduction from inherited constructors, but the wording wasn't ready in time.
Using enum
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.
Conversion to arrays of unknown bound
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
More implicit moves
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 movesDeprecating some uses of volatile
Expressions such as ++ or += that involve both load and store of a volatile lvalue are deprecated, as are volatile-qualified parameter and return types.
Deprecating comma in subscripting expressions
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
Interaction of memory_order_consume with release sequences
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.
Last updated: August 30, 2019