Report from the February 2020 ISO C++ meeting (Core Language Working Group)

The first International Organization for Standardization (ISO) C++ meeting of 2020 happened in Prague, Czechia. It was our first time meeting in Prague, though I've been there a few times for the GNU Tools Cauldron. Two of us from Red Hat attended: Jonathan Wakely serves on the ISO C++ Standards Committee Library Working Group (LWG), and I am part of the Core Language Working Group (CWG). (You can see the ISO C++ committee structure here.)

This was our second meeting after sending the C++20 draft standard out for comments from the ISO C++ national bodies. We finished responses to the last round of comments. That went well, and at the end of the week, we voted to send the resulting C++20 standard to the national bodies for ratification.

In the next sections, I'll share the thinking behind some of our decisions. Note that this report addresses mostly lower-level issues, unlike my usual trip reports.

Concepts

As part of my work on concepts, I contributed wording to the resolution of two closely connected issues.

Clarify declaration matching

The first issue is documented in CA104 13.04 [temp.constr]: Clarify declaration matching and partial ordering requiring substitution into constraints. Normally, we try to avoid substituting directly into constraints as written in a requires-clause. Instead, we prefer substitution only on atomic constraints as part of determining whether requirements have been satisfied.

In the case of comparing a declaration at namespace scope to a declaration in an instantiation of a class template, however, we must allow a direct substitution in some instances. One example is determining whether a specialization matches:

template <class T> struct A {
    template <class U> U f(U) requires C<typename T::type>;
    template <class U> U f(U) requires C<T>;
  };

// Substitute int for T in above requirements to find match.
  template <> template <class U> U A<int>::f(U) requires C<int>  { }

Hidden non-template friends

The second issue is from US115 13.6.4 [temp.friend]: Hidden non-template friends need a requires-clause. Until now, it was considered ill-formed for a non-template friend declaration to have a requires-clause. The ISO C++ committee reasoned that it would be unclear whether the non-template friend declaration was trying to match a given constrained overload, or if it was trying to declare friendship only if the requirements are satisfied. We determined that removing constraints on non-template functions renders the first concern meaningless. The second concern remains an undesirable difference from constraint semantics in all other situations.

If the friend is defined in the class body, then having a requires-clause makes just as much sense as it does on a member function. That is, the clause can be used to define a particular operation for a class template, depending on the characteristics of the template arguments. The library was already allowing this behavior even though the language said it was invalid.

We resolved to allow the requires-clause on a friend that is defined in a templated class. To avoid the kind of substitution needed for partial specialization matching (as shown in the code sample), we said that any friend template with a constraint that depends on a template parameter of the class must also be defined in the class body. If the constraint only depends on the friend's template parameters, it can be a declaration to match with a template defined at namespace scope.

Changing concept values

Continuing with concepts, we addressed Disallow changing concept values. This paper resolves GB046 as "accepted with modifications."

We noticed when working on concepts in the G++ compiler that the draft allowed the satisfaction of a declaration to vary within a translation unit. This meant, for example, that a declaration could be satisfied by a class becoming complete. Supporting this change slows down the compiler because we could no longer remember the results of a previous check across events such as completing a class definition. The decision to disallow changing concept values means that we don't have to worry about that problem, and we can speed up the compiler again. As a caveat, the current resolution breaks a fair amount of concept code, so more investigation is needed.

Function template constraints

For the Proposed resolution for 2019 comment CA 112, we resolved to clarify that a function template can only be considered more constrained than another if the template parameters are otherwise equivalent.

Modules

We addressed three proposals dealing with the complications of entities that were once local to a translation unit. In a module interface unit, such entities could become visible to importing translation units:

• P1815R2: Translation-unit-local entities makes it ill-formed for an exported declaration to expose a translation-local entity.
• P1779R3: ABI isolation for member functions makes functions defined in a class body within a module no longer implicitly inline, so that they can use local entities without exposing them.
• P2115R0: Merging of multiple definitions for unnamed unscoped enumerations deals with how we merge unnamed file-scope enumerations from header files that might not have the same set of enumerators in different translation units.

Each of these patterns previously violated the one definition rule (ODR) but worked in practice. Note that a compiler is free to inline a function that is not declared inline, so the P1779 change need not affect performance. On ELF targets such as GNU/Linux, which allow symbols to be overridden by other definitions, the GNU Compiler Collection (GCC) currently does not inline replaceable functions unless the user specifies -fno-semantic-interposition. We could address this issue in the GCC Modules implementation by assuming no interposition for functions defined in a module interface unit.

Miscellaneous

We also addressed several miscellaneous papers. One of these, P0593R6: Implicit creation of objects for low-level object manipulation, offers a new model for when objects are considered to have been created in malloced memory or a char buffer. Any objects necessary are considered to have been created implicitly by the malloc or creation of the buffer. The new model should bring more clarity to type-based aliasing rules in C++.

We also addressed the proposal P1957R2: Converting from T* to bool should be considered narrowing. It was surprising to realize that we had not previously considered a pointer-to-bool conversion to be narrowing; however, experimentation suggests that making that change would result in far more bugs than false positives.

The resolution to P1937R2: Fixing inconsistencies between constexpr and consteval functions states that a consteval call can no longer be immediately evaluated in an unevaluated context.

Conclusion

The next meeting was scheduled for June 2020 in Varna, Bulgaria. It has been postponed indefinitely due to COVID-19.