Title: The Standard Report

Author: Bob Schmidt

Date: 04 July 2020 16:58:39 +01:00 or Sat, 04 July 2020 16:58:39 +01:00

Summary: Guy Davidson reports on the latest developments.

Body: 

Since my last report, several C++ committee groups have been meeting for regular telecons. SG14 has held a monthly telecon for over five years now. Now the Library Evolution Working Group (LEWG) and the Evolution Working Group (EWG) are meeting weekly. As I mentioned last month:

Library Evolution meetings are scheduled for alternating Mondays at 15:00 UTC and Tuesdays at 17:00 UTC, while Evolution meetings are scheduled for alternating Thursdays at 17:00 UTC and Wednesdays at 15:00 UTC. This works out at early morning for the US West Coast, lunchtime for the US East Coast, teatime for the UK and dinnertime for Europe (or thereabouts).

This pattern has held and is working well. There is one problem for your author: as I also suggested last month, making time in the working day for two 90-minute meetings a week is rather tough, and I have had to set EWG participation aside in favour of attending the LEWG telecons. I have library papers in flight and I should keep my hand in the process.

There are some large issues being discussed in LEWG at the moment. Let’s start with the modularisation of the standard library, https://wg21.link/P0581. Unless you are new to C++ or you have been living somewhere with no internet, you are probably aware that C++20 saw the introduction of modules to the language. This feature brings more semantic heft to the matter of repeated declarations, hitherto supported only by the preprocessed inclusion of header files. The good folk of cppreference.com are gamely assembling their C++20 documentation, and you can check out their current efforts on describing modules at https://en.cppreference.com/w/cpp/language/modules. Modules introduce a way of creating components, and there is hope that it may improve compilation times as well by mimicking the behaviour of precompiled headers.

Of course, now that we have modules, we should put them to work in the standard library and practice what we preach. The question that needs answering is “how do we divide up the standard library into modules?” Do we have one big module for the entire standard library, or a few modules for IO, STL and so on, or lots of small modules at the per-container level?

After 90 minutes of discussion, voting revealed that we don’t like intermediate sized modules, but we like the idea of both fine-grained modules and one module for the entire library. We will have to decide which later. There was also an interest in having a single module for the freestanding implementation. Of course, the biggest problem is that there is no field experience of modules, and making decisions about modularising the standard library is possibly unwise before we accumulate that.

Let’s stay with freestanding and consider the developments there, which you can review at https://wg21.link/P1641 and https://wg21.link/P1642. Freestanding implementations don’t have an OS, which can make things like allocation and exception handling difficult and require the creation of a separate dialect of C++. This is not a great idea, as this bifurcates the language. There is a simple solution: mark parts of the standard with // freestanding to highlight that it should be available to freestanding implementations as well as to hosted implementations. So far, the [utilities], [ranges] and [iterators] clauses have been reviewed for qualification as freestanding components.

Another big-ticket item that needs library support is coroutines. Experimental support for coroutines has been available in the Microsoft implementation for a while now, and one thing that has emerged is that it would be useful to be able to constrain a generic function to only accept parameters to which you can apply the co_await operator. https://wg21.link/P1288 seeks to provide a way to offer that to the standard library. The use of the word constrain should highlight that this is achieved through the definition of appropriate concepts.

Concepts both satisfy and constrain, so the idea of introducing one to the standard is slightly unnerving: once a concept symbol is in the library, it can’t be relaxed or tightened. Given that, as with modules and coroutines, we don’t have much field experience of concepts, the idea of proposing a feature which makes use of two new features seems slightly hazardous.

This proposal contains some concepts, type traits and helper functions. The review focused on the concepts. co_await cannot be used in an unevaluated context like decltype because it is context dependent: the result of a co_await expression depends on things like the promise type. This makes it devilishly hard to write a concept that accurately answers the question “Can I co_await on this thing?” Ultimately, the paper was welcomed but needs another revision to more clearly address these matters.

Finally, a matter close to my heart: linear algebra. There are two papers in flight on this subject, https://wg21.link/P1385 and https://wg21.link/P1673. The first of these has some involvement from me and has yet to receive LEWG review. The second is a proposal to insert a BLAS interface into the standard library.

The problem it is trying to solve is that the BLAS is supremely battle hardened, but it has achieved this through age and has an inappropriate API for C++. The interface has already been standardised with bindings for C and FORTRAN, but that has baked the types on which it operates into the API. The function signatures are unintuitive and unhelpful, with names like DGEMV, taking eleven parameters, for multiplying a matrix by a vector composed of elements of type double.

The paper proposes function templates with more meaningful names, such as triangular_matrix_vector_product instead of DTRMV. It is well on its way to completion: it has 13 authors and is fully worded.

Next time I’ll cover more of the LEWG reviews, and also cover the work EWG if there are sufficient papers of general interest. There may also be developments on my own paper.

Guy Davidson Guy Davidson is the Principal Coding Manager at Creative Assembly. He has been writing games for about 75% of his life now. He is climbing through his piano grades and teaching Tai Chi while parenting in Hove and engaging in local political activism.

Notes: 

More fields may be available via dynamicdata ..