Title: The Standards Report

Author: Bob Schmidt

Date: 04 September 2019 17:15:59 +01:00 or Wed, 04 September 2019 17:15:59 +01:00

Summary: Guy Davidson provides his latest report.

Body: 

In this report, I’m going to cover the new language proposals that were voted into the standard at the recent meeting in Cologne. Twenty-five motions came before the committee from the Core Working Group (CWG) for voting. Rather than iterate through them all, I shall present some highlights. Recall that any paper can be reviewed by visiting wg21.link and appending the proposal number; for example, https://wg21.link/P1000.

The biggest news from CWG was P1823, ‘Remove contracts from C++20’. It is very hard to remove things from the International Standard. Once code is written against the standard, any change which renders that code non-conforming will carry considerable political impact. Engineers are faced with the choice of either rewriting their code or freezing their C++ implementation at a point prior to this change. Neither of these is particularly palatable, and they both weaken confidence in the language and the committee. Therefore, if a feature turns out to be incorrectly specified, no matter how popular it is, it needs to be withdrawn before it creates greater damage outside of the committee.

In the case of contracts there were a number of problems, as outlined in the motivation of the paper:

Is this the end of contracts? Not at all. A new study group, SG21 Contracts, chaired by John Spicer of Edison Design Group, was formed to finish contracts. I wish them the best of luck.

Having mentioned how tricky it is to withdraw features from the standard, I must mention P1152, ‘Deprecating volatile’. The title is a little deceptive: this isn’t a wholesale removal of the keyword from the language. In particular, from the wording, we see that:

Postfix ++ and -- expressions ([expr.post.incr]) and prefix ++ and -- expressions ([expr.pre.incr]) of volatile-qualified arithmetic and pointer types are deprecated.

Certain assignments where the left operand is a volatile-qualified non-class type are deprecated; see [expr.ass].

A function type ([dcl.fct]) with a parameter with volatile-qualified type or with a volatile-qualified return type is deprecated.

A structured binding ([dcl.struct.bind]) of a volatile-qualified type is deprecated.

Many clauses describing the use of volatile remain unchanged. Take a look at the paper for more information on how we got to this point, particularly in the earlier revisions.

An interestingly innocent-looking motion that was passed was P1161, ‘Deprecate uses of the comma operator in subscripting expressions’. Particularly, in this example:

  void f(int *a, int b, int c) {
    a[b,c];   // deprecated
    a[(b,c)]; // OK
  }

This suits me very well: I am co-authoring a linear algebra proposal and this allows us to use the comma operator for multidimensional subscript operators, essential for classes such as matrix.

The mission to ‘constexpr all the things’ continues apace with four excellent proposals. P1331, ‘Permitting trivial default initialization in constexpr contexts’, proposes permitting default initialization for trivially default constructible types in constexpr contexts while continuing to disallow the invocation of undefined behavior. So, as long as uninitialized values are not read from, such states should be permitted in constexpr in both heap and stack allocated scenarios.

P1668R1, ‘Enabling constexpr Intrinsics By Permitting Unevaluated inline-assembly in constexpr Functions’, does what it says on the tin: constexpr functions may now contain assembly.

My favourite of these, P1143R2, ‘Adding the constinit keyword’, saves us from the Static Initialisation Order Fiasco. Static storage duration variables with dynamic initializers cause hard-to-find bugs caused by the indeterminate order of dynamic initialization. By qualifying them with the constinit keyword they are initialised at compile time, on the condition that their constructors are constexpr. I am STILL caught out by the SIOF even after thirty years of C++. I still see it in code reviews, and it simply isn’t going away. This mitigation is most welcome.

Finally, P0784, ‘More constexpr containers’, enables more containers to be constexpr. It achieves this by introducing constexpr destructors, constexpr new-expressions and enabling the use of the default allocator in constant expressions. This is going to be important for the upcoming reflection and metaprogramming API: all of the compile time introspection will require variable sized containers, currently impossible without these features.

The [[nodiscard]] attribute also gained some weight. P1301, ‘[[nodiscard("should have a reason")]]’, delivers the potential for improved compiler diagnostics. From the paper:

The [[nodiscard]] attribute has helped prevent a serious class of software bugs, but sometimes it is hard to communicate exactly why a function is marked as [[nodiscard]].

This paper adds an addendum to allow a person to add a string attribute token to let someone provide a small reasoning or reminder for why a function has been marked [[nodiscard("Please do not leak this memory!")]].

Finally, there was an interesting procedural point for P1714R1 (NTTP are incomplete without float, double, and long double!). This paper was brought to the committee after the feature freeze, and although it is a good paper with strong motivation, we had to decide if we could allow it in at this late stage. By now, proposals should either be reviewed and completed work, or bug fixes. The question was asked of the implementers present in the room: do you think this is a bug-fix? They unanimously answered “No”. We voted to discard the motion to add this proposal: we voted not to vote. This averted setting a precedent that is unhelpful to our process. I look forward to this proposal entering the next Working Draft at the appropriate time, which I expect will be at closing plenary of the Summer 2020 meeting in Bulgaria.

In my next report I will discuss the library changes that were made in Cologne.

Notes: 

More fields may be available via dynamicdata ..