Report from the February 2019 ISO C++ meeting (Core Language working group)

The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three developers to the meeting: I attended in the Core Language working group, Jonathan Wakely in Library, and Thomas Rodgers in SG1 (parallelism and concurrency). The meeting went smoothly, although there was significant uncertainty at the beginning where we would end up. In the end, Modules and Coroutines were accepted into the C++20 draft, so now we have our work cut out for us nailing down the remaining loose corners. Here ar highlights from the meeting.

Modules

Work on Modules is very much continuing at this point. All of the Evolution group's Tuesday discussions, and some later in the week, were on various subtleties of Modules, particularly around argument-dependent lookup.  A Monday evening discussion also covered the tooling challenges. I haven't been following the design discussions very closely, as Nathan Sidwell is in charge of Modules in GCC, but it seems like we're converging on a solid design, with various proofs of concept to address concerns. The global module fragment still makes me nervous, but now that we have header units as well, I'm satisfied that it won't be a huge problem.

Coroutines

Coroutines took up all of Wednesday in Evolution. In addition to the Coroutines TS and Core Coroutines proposals that have been under discussion at past meetings, a third design was presented, referred to as "Symmetric Coroutines." There was a lot of comparison of the different approaches—comparing the different choices made by the different proposals and considering possibilities for future convergence between them. In the end, Evolution voted strongly to go ahead with the design in the Coroutines TS.

Contracts

Contracts was voted into C++20 at an earlier meeting, but the topic still took up all of Monday. There were two competing proposals to address some people's nervousness about "assuming" a contract condition such that it affects optimization of paths of execution that include the contract.

It has always seemed to me that if you have contracts that can continue, those conditions must not be assumed by subsequent code. But, if a contract check cannot continue, naturally the check can be assumed by subsequent code, because if it had been false execution would not have continued. So, the question of whether a condition can be assumed reduces to whether or not the check can continue. The two proposals both wanted to increase explicit control over this, one by adding the "continue" keyword to the constructor, and the other by introducing explicit semantics like check_maybe_continue to be used instead of contract levels like "default." I'm sure we'll see more about this at the next meeting.

There has also been nervousness about backward propagation of assumed conditions based on the existing wording that an unchecked contract that would have failed is undefined behavior; compilers optimize based on the assumption that undefined behavior can't happen, and mark code as unreachable accordingly. I think this worry is exaggerated, because back-propagation of undefined conditions happens in most optimizers already (e.g., with null pointer dereference) and this would just make the conditions clearer. Checked contracts wouldn't back-propagate, as the contract handler might not return.

One proposal was made to change "expects"/"ensures" to "pre"/"post"; this suggestion was well received and will probably go in at the next meeting.

Reflection

Core spent a while on responses to national body comments on the Reflection TS, and the TS as changed was approved for publication. It's unclear whether this approach to reflection (using magic types) will end up being the one that goes into the standard, but we think it's well specified at this point.

Here are some of the smaller papers that went in:

Extending structured bindings (P1091R3, P1381R1), which allows structured bindings to be declared static and thread_local and to be captured by lambdas.

Allow initializing aggregates from a parenthesized list of values, so now all aggregate classes can be initialized using the normal syntax for calling a constructor, with similar semantics. For example, in a constructor call, a temporary bound to a reference member is not extended, and braces are not elided. This was requested to support usage by library object factory functions like make_unique.

Array size deduction in new-expressions, allowing new T[]{ ... } to deduce the size of the allocated array from the initializer, like we do already for variables.

<=> != ==, which changes defaulted operator== to use member == rather than <=> for reasons of efficiency.

Here are some other papers we looked at, which weren't quite ready this week:

Filling Holes in Class Template Argument Deduction, which proposes to allow CTAD for aggregates, alias templates, and inherited constructors.

Conditionally Trivial Special Member Functions, which aims to allow a constructor with certain (Concepts) constraints to be trivial while a constructor with different constraints is not, and have whether the class is trivially copyable depend on which is selected for a particular instantiation of the class.

The next meeting will be in July in Cologne, Germany.