November 2018 ISO C++ meeting trip report (Core Language)

The ISO C++ standards meeting in November 2018 was held in San Diego, CA. As usual, Red Hat sent three of us to the meeting: me (for the Core Language Working Group), Jonathan Wakely (for the Library Working Group [LEWG]), and Thomas Rodgers (for the Concurrency and Parallelism Study Group [SG1]). I felt the meeting was productive, though some features that had been expected to make it into C++20 are now in question.

Here are new C++ features accepted at the meeting:

• Expanded constexpr: Constant expressions can now include try blocks (in a constexpr function), dynamic_cast, and typeid, but only if they wouldn't throw an exception. Throwing an expression still makes the expression non-constant. Constant expressions can now also change the active member of a union created during constant evaluation.
• char8_t: A specific type for UTF-8 code units that also doesn't have the aliasing issues of the C char type.
• immediate functions ("consteval"): A stronger form of constexpr functions that are always immediately evaluated for a constant value. I'm still not convinced this is a sufficiently useful distinction from normal constexpr functions, but others seem rather keen on it.
• std::is_constant_evaluated(): Allows constexpr functions to use one implementation during constant evaluation and a more efficient but non-constexpr implementation during runtime evaluation.
• Nested inline namespaces: Adds support for declaring inline namespaces to the C++ nested namespace definition feature.
• "Constrained auto": Most significantly reintroduces abbreviated function templates from the Concepts TS with somewhat different syntax; instead of declaring a function parameter of constrained generic type with just the name of a type concept, you do it with the concept followed by "auto", for example:

  auto f(Copyable auto x) { return x; }

Here are various other proposals we discussed at the meeting:

• P0881R3, a new proposal for a stack trace library: This seemed to Core like it was going too far toward reflection; the design needs more time to bake.
• P1103R2, Merging Modules: The unified module design continues to progress and is expected to make it into the working paper at the next meeting.
• Two papers about operator <=> ("spaceship"), P1185 and P1186:
  • 1185 points out that an == operator that just calls the <=> operator can be significantly slower than one written to call == for the subobjects. The design is still somewhat in flux, but there seems to be a strong consensus that we want to change this and change non-type template arguments of class type to depend on == rather than <=>.
  • 1186 proposes allowing defaulted <=> to use existing < and == operators, since most existing classes don't themselves have <=>.  But this ran into trouble; for more details, see the author's post.

  With these issues arising, people have become uncertain whether <=> is actually ready to be part of C++20, but it seems to me that there's enough time left to resolve things.

• P1328R0, making type_info::operator== constexpr: This seemed like an obvious fix to me.

We even found the time to talk about submitted issues between the papers. Many were of limited interest to folks outside the committee, but issue 2362 argues that __func__ should be constexpr. Core is inclined to move in the opposite direction, by changing its type from array to pointer, in order to avoid making the size of the name usable in a constant-expression. On reflection now, I'm not sure this is such a good idea; there are plenty of ways to get an ODR violation, and I'm not sure this one would be bad enough to prevent uses that people want for it. We referred this issue to Evolution for input.

The next meeting will be in Kailua-Kona, Hawaii, in February.