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:

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 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.

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 initializer

Unevaluated 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 constant

More 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 moves

Deprecating 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.