Title: ACCU Standards Report

Author: Bob Schmidt

Date: 04 January 2019 16:08:57 +00:00 or Fri, 04 January 2019 16:08:57 +00:00

Summary: Emyr Williams reports the latest from the C++ Standards meetings.

Body: 

The ISO Committee for C++ met in San Diego California a few weeks ago, hosted under the auspices of Qualcomm. It was an exceptionally well attended meeting, with nigh on 180 people attending, which is the largest gathering for the C++ Committee meetings.

While the meeting was slated to be one of the last meetings for adding features in to C++ 20, the committee were eager to ensure that priority was given to proposals that might actually make it in to C++20. And this was no mean feat given that the pre-meeting mailing was 274 papers. Therefore, quite a number of papers to get through.

A good number of things made it through to C++20, and as ever some of the highlights are mentioned here. But before I go in to that, I would like to offer my sincere thanks to Roger Orr and Herb Sutter for being gracious enough to proof read what I’ve written and helping me to make sure that what I’ve written is an accurate reflection of what occurred in San Diego.

Ranges (p0896r3)

Ranges was adopted for C++ 20. This was due to a herculean effort from the authors, indeed my gmail inbox bears testimony to this. It has an amazing tribute (if that’s the right word) to J.R.R Tolkien on its front page.

Casey Carter’s git repo for Ranges can be found here: https://github.com/CaseyCarter/cmcstl2

Concepts Convenience notation for constrained templates (P1141r1)

(Or ‘concepts with a terse syntax’.)

This paper proposed to shorten the syntax for the constrained declaration of function parameters, function return types and variables. This means that in most cases, we’ll no longer need to use the word ‘template’ or use ‘requires’ which can lead to code that no longer looks like this:

  template <typename T> requires Sortable<T>
  void sort (T &target)
  {
    …
  }

But rather looks like this:

  void sort(auto Sortable &target);

Now, C++ will let you write many generic functions without the template keyword or angle brackets. The proposal as adopted means you’ll typically need to use auto (which indicates that you are writing a generic function), part 2 of the proposal, which was not adopted, would allow you to simply use a concept name.

Now Herb mentioned in his blog, that “C++ will now let you write lots of generic functions without ‘template’ or angle brackets, and that are concept-constrained and therefore much easier to use correctly than function templates have ever been before.” Which led me to wonder, “What cases would it NOT let you write generic functions without the ‘template’ keyword and the angle brackets.”

Herb was gracious enough to e-mail me an answer, so my deep gratitude for his answer.

There are still instances where you’ll need to use both keywords.

The right way to think of it is that the terse syntax is to make common cases easy, not to be a fully general syntax. (We already have one of those.)

The terse syntax will never cover all concept cases, and it doesn’t currently cover some that it could in the future, such as multi-type concepts. So if you wanted to write something like:

  template<class In1, class In2, class Out>
     requires Mergeable(In1,In2,Out)
     Out merge(In1, In1, In2, In2, Out);

then there is currently no shorter way to say it. Templates like this one still have to be written with the full elaboration, but many common ones can be written without the template keyword.

C++ and Constexpr programming.

There has been quite a surge in compile-time programming features to C++ 20. This has been coming for a while and it’s important for the current evolution of C++ as it becomes important to enable us to make effective use of compile time reflection.

This has been on the cards since we were given:

• Simple constexpr functions in C++ 11, i.e. a single return statement.
• constexpr with loops in C++ 14
• constexpr lambdas and ‘if constexpr’ in C++ 17

Yet more compile time features have been added to C++20, the highlights include:

• consteval immediate functions (p1073r2) While the constexpr specifier applied to a function or member function can indicate that a call to that function might be valid in a context needing a constant expression, it does not require that every such call be a constant-expression. However, there are times that programmers would want to define a function that should always produce a constant when it’s called, whether that be directly or indirectly, and that a non-constant result should produce some kind of error.

  The aim of the paper was to address this issue. This allows developers to write functions that are guaranteed to be run at compile time. This work is essential for the kind of code generation that Herb’s Metaclasses proposal will later rely on, as well as for the proposed future direction of refection.

• constexpr union (p1330r0) Allows developers to change the active member of a union at compile time. What does this give us? Well, some containers like std::string and std::optional use unions inside their implementations. And at the present time, changing an active element of a union isn’t currently allowed in a constant expression. The idea of this paper is to help pave the way towards std::string becoming constexpr-friendly.
• constexpr try/catch block (p1002r0) This allows developers to write try/catch blocks in constexpr code. The motives for this was to help with reflection and with metaprogramming. The paper also stated that the limitation for this was encountered while looking at std::vector in libc++ with the view of making it constexpr enabled, as vector::insert uses a try-catch block to provide the strong exception guarantee. This paper should dovetail nicely with the paper Standard Containers and constexpr (P0784r1)

  It should be noted however, that this doesn't actually allow you to throw exceptions at run time.

• constexpr dynamic_cast and polymorphic typeid in constant expressions (p1327r0) There are a number of proposals to improve std::error_category which added new members or new virtual functions to it. Changing a standard polymorphic type is an ABI (Application Binary Interface) break, and this is something library writers are seeking to avoid.

  This paper aims to solve this by adding the ability to use dynamic_cast in constant expressions.

• std::is_constant_evaluated (p0595r1) Allows for conditional code to be written that lets you write part of a function using code that is guaranteed to be executed at compile time.
• constexpr std::pointer_traits (p1006r1) This is essential for enabling compile time reflection and to enabled std::vector to become constexpr. (The latter is dependent on constexpr new, which is still under development at this time.)

Modules

Modules now has an approved unified design targeting C++ 20. As such there is more work to be done on wording; however, it is expected that the committee will consider modules at the next meeting in February.

Coroutines

There is still a lot of work being done with coroutines. EWG recommended merging the coroutines TS (n4774) in to C++, and the also planned to include features from Core Coroutines (p1063r1) proposal as well. However, the vote to merge the TS fell just short of the required numbers, so it wasn’t adopted for C++ 20 at this meeting.

However, with collaboration from Facebook and other companies, there will be more work done over the winter to address the concerns that remain, as well as doing further merging work from the Core Coroutines paper in to the TS. It’s expected that coroutines will be proposed again at the next meeting (Kona), with the new information, and it will give the national bodies time to get their heads around this new information.

Executors

Due to the progress between the previous ISO meetings, and some special meetings in between, it’s starting to look like an initial executors design could make it for C++ 20. While the paper wasn’t merged in San Diego, the design was approved, and again it’s a case of working on the wording, which will be discussed at the next meeting.

Networking

For a while now, it has been known that this work is dependent on executors, and there has been discussions about decoupling the parts that are reliant on executors so that there is at least some networking functionality in C++ 20. However, it was decided at the meeting to target merging the Networks paper in to C++23; while this is disappointing, it also gives the committee time to work through whether there is integration work to be done with merging Networking with Coroutines.

New groups…

A number of study groups were formed at the meeting, as well as two incubator study groups.

• SG13 – Human-Machine Interface Study Group was reformed with ACCU’s very own Roger Orr as chair, and will be working on figuring out what the next steps are for the 2D graphics proposal. They met at San Diego, and spent half a day or so scoping the work they were going to tackle. It’s highly probable that an extra meeting specifically for 2D graphics in C++ will be held with the purpose of trying to get feedback from experts in the field.
• SG19 – Machine Learning Working Group, chaired by Michael Wong was formed to take advantage of C++’s strengths in generic programming, as well as code portability for the specific area of Machine Learning. The main aim of the SG19 group is to work on improving C++’s ability to support:
  • Fast iteration
  • Arrays
  • Matrices
  • Linear Algebra
  • In memory passing of data for computation
  • Optimisation for graph programming

  to name a few highlights.

• SG20 – Education, chaired by JC van Winkel was formed to improve the quality of C++ education, and to enable developers to use the language, its features and ecosystem to write correct, maintainable and performant software. The group will aim to create a set of guidelines for a educational curriculum for various levels of expertise and application domains, as well as encourage WG21 paper authors to include guidance on how to teach the new feature they are proposing to add to the standard.

A pair of incubator groups were also formed. The intention is that these groups will be additional stages in language and library evolution pipelines. Their focus is to refine, merge and filter new and forward-looking proposals and to ensure that effort is focussed on delivering C++’s long term strategic goals. The groups are as follows:

• SG17 – The Evolution Working Group Incubator, chaired by JF Bastien. The idea behind this was that the EWGI would be able to look at papers that the EWG wouldn’t have time to look at. They worked through about 30 papers at the meeting, and sent a few onwards to the EWG. These were:
• nodiscard should have a reason (p1301r0) (This paper will also be sent to the LEWG, as they could want to add reasons to existing uses of nodiscard in the standard library.)
• Array size deduction in new-expressions (1009r0)
• Make char16_t and char32_t string literals be UTF-16/32 (p1041r1)
• Named character escapes (p1097r1)
• Using enum (p1099r2)
• SG18 – The Library Evolution Working Group Incubator (LEWGI), chaired by Bryce Adelstein Lelbach. The main role of the LEWGI is to give directional input on proposals as well as early design reviews. During this meeting they were focussing on post C++ 20 content, however some things were sent for consideration for C++ 20 such as std::unique_function (p0288r1) which is similar to std::function except it doesn’t have a copy constructor or copy assignment operator, which allows it to wrap function objects containing non-copyable resources.

Emyr Williams Emyr is a C++ developer who is on a mission to become a better programmer. His blog can be found at www.becomingbetter.co.uk

Notes: 

More fields may be available via dynamicdata ..