Title: Standards Report

Author: Bob Schmidt

Date: 05 May 2018 17:37:10 +01:00 or Sat, 05 May 2018 17:37:10 +01:00

Summary: Emyr Williams reports on news from the world of Standards.

Body: 

The first ISO C++ committee meeting of 2018 was held in Jacksonville, Florida where work continued apace to work on the Technical Specifications, as well as the next version of C++ which would be C++20. Once again making use of the various trip reports, and with my eternal thanks to the people who've written one, I've been able to cobble together what are the main things discussed. I would like to thank Roger Orr for proofing and correcting where necessary.

C++ 17 - Compiler update

As my previous report stated, C++ 17 has now been officially published. However, it's worthy to note that the latest versions of GCC and Clang both have complete support for C++ 17, apart from a few bugs. And Microsoft's C++ compiler MSVC has significant partial support, but they are making good progress towards full support.

C++ 20 Language

Language support for empty objects. (P0840R0)

While we already have an empty base optimization, C++ 20 will have additional features for the creation of empty objects. This is achieved using the no_unique_address attribute. This tells the compiler that a unique address in memory isn't required for a non-static data member. This means that we can compose without overhead and without needing to use inheritance, which can be troublesome as it 'leaks out'. It also means that the data member can share its address with another object, as long as it could have a zero size, and they're both distinct types.

  template <typename Key, typename Value, 
    typename Hash, typename Pred, 
    typename Allocator>
  class hash_map {
    [[no_unique_address]] Hash hasher;
    [[no_unique_address]] Pred pred;
    [[no_unqiue_address]] Allocator alloc;
    Bucket *buckets;
  }

In the example above, the hasher, pred and alloc objects could have the same address as the Buckets object if their respective types are all empty.

Down with typename (P0634R2)

This proposal removes the requirement to use the typename keyword as a disambiguator in some contexts. The proposal is that typename is made optional in a context that are known to only permit type names.

Allow structured bindings to accessible members. (P0969R0)

Structured Bindings was one of the last-minute additions to C++ 17, and with use users have come across new issues and ideas to make it better. Timur Doumler, who's a member of the BSi panel proposed a paper to enhance structured bindings. The original wording only allowed binding to public members, however Timur's paper proposed to allow binding to any accessible data members. It will be in C++20, however it is treated as a defect for C++17.

Relaxing the range-for loop customization point finding rules. (P0962R0)

This resolves a set of corner cases for the range-based for. At present, you cannot write a range-based for loop over data that comes through an input stream without writing an adaptor class. While this may surprise a few of us, the paper's author was concerned that the committee have painted themselves in to a corner where such support cannot be added. The issue is that seekdir::end is found, and this makes it impossible to find begin() and end() with any degree of certainty.

The paper also provides a code sample that wouldn't work in C++ 17, however it would work in C++ 20.

  #include <sstream>
  #include <iterator>
  struct X : std::stringstream
  {
    // do some stuff here
  };
  std::istream_iterator<char> begin(X& x)
  {
    return std::istream_iterator<char>(x);
  }
  std::istream_iterator<char> end(X& x)
  {
    return std::istream_iterator<char>();
  }
  int main() 
  {
    X x;
    for(auto&& i : x)
    {
      // do stuff here
    }
 }

Parallelism TS v2 Complete, sent for national body balloting.

The new version of the Parallelism TS was completed, and a draft has been sent for national body balloting, so I expect that will be discussed at the next BSi Panel meeting in London.

Attributes for [[likely]] and [[unlikely]] (P0479R4)

One of the things compilers have been doing for quite some time now, is branch-execution optimisations, but it has tended to be non-portable. One of the new things coming in C++20 is the ability to mark which is the likely branch to be executed, and it will give that information to the optimiser. So for example:

  if(foo < bar) [[ likely ]] {
    // do something neat here…
  } else {
    do_other_thing();
  }

You can also tell the compiler what is not usually executed, so for example:

  while( foo > bar ) {
    [[unlikely]] create_widget();
  }

This can be used for any scenario where branching occurs, such as a switch statement, a nested if statement, or any of the loops.

There was discussion about the name, since the attribute can also be used for statements executed when rare events occur that needs the faster path. So that's worth bearing in mind.

Coroutines (P0912R0)

The proposal to merge coroutines was delayed, pending papers giving feedback from the TS, especially the one from Google, however this will be visited again in the next meeting in Rapperswil.

New work item proposals created

There was a move to direct the Convener, to request a New Work Item for a Technical Specification on "C++ Extensions for Reflection" and create a working draft with "Static Reflection" (paper p0194r6) as its initial content.

Symmetry for <=> (P0905R0)

The idea behind the paper was to make operator spaceship symmetric, so that when a <=> b is well formed, then b <=> a should also be well formed and have the complementary semantics. This is helpful for mixed-type comparisons where the operator was only defined in one direction.

Library Evolution Working Group

Much work and effort was made to advance the case for using concepts and modules in the standard library. The Standard Library Concepts paper (p0898r0) was sent to the Library Working Group for a wording review.

The group also worked on a plan to merge the Ranges Technical Specification Version 1 in to C++ 20. So far there hasn't been a consensus on where range-based algorithms should go just yet. There was previous discussion in regard to placing them into a new namespace (std2) however it looks more likely that they will be placed in std::ranges.

C++ 20 Library

A <version> header (P0754R1)

This would be a new header file with implementation-dependent version information. The information that could be found in this file, may well be different in each implementation and be specifically related to the vendor. This will replace the <ciso646> header file, as it was being hijacked by some vendors as a good place to put vendor-specific defines, which went against the original purpose of the header.

Comparison of Unordered Containers. (P0809R0)

At present, the comparison of unordered containers causes undefined behaviour unless Hash and Pred have exactly the same behaviour for both containers. This means that two different hash functions may lead to containers being different.

Major feature developments timeline

Herb Sutter created a timeline of what's coming when, although he was at pains to point out that this was a plan, and not a promise, so it should be treated as speculative and tentative. It is shown in the table below, which uses the following terms:

• CD = Committee Draft
• IS = International Standard
• TS = Technical Specification

Feature	Status	Depends on	Current target (conservative estimate)	Current target (optimistic estimate)
Concepts	Concepts TS v1 published and merged in to IS		C++20	C++20
Ranges (N4128)	Ranges TS v1 published	Concepts	Core in C++20 and rest in C++23	C++20
Contracts (p0542r3)	Proposal		C++23	C++20
Modules (P0678r0)	Modules TS v1 published		C++23	C++20
Coroutines (N4723)	Coroutines TSv1 published		C++23	C++20
Executors (p0761r2)	Proposal		C++23	C++20
Networking (N4711)	Networking TS v1 published	Executors	C++23	C++20
New future and async	Concurrent TS v1 published	Executors	C++23	C++20
Reflection (p0194r5)	TS Working Paper		TS in C++23 timeframe and IS in C++26	TS in C++20 timeframe and IS in C++23

Notes: 

More fields may be available via dynamicdata ..