Table of Contents

Today is the start day of Summer C++ISO meeting, this time in Cologne, Germany! This is the “feature-complete” meeting for C++20. It’s the last time we’ll see some new elements that are merged into the working draft.

Let’s see what’s already in C++20 and let’s have a look at some smaller, but very handy proposals that might get into the standard. This is similar to article that I did for Kona and San Diego Meetings.

Update! 20th July 2019: Cologne Meeting has just ended, and we have a nice report what happened. See r/cpp: Cologne ISO C++ Committee Trip Report .

What’s Already in C++20*  

Thanks to various trip reports and especially r/cpp threads we can gather a list of features that are already merged into C++20. I tried to list the most essential elements.

(*) Although a lot of items are “merged” into the working draft of the Standard, it’s still not 100% guaranteed that a particular feature will be in the final Standard. There are several review stages that the whole draft has to pass.

At cppreference there’s also a single list with all C++20 features: C++2a features

Toronto, July 2017  

The first meeting that discussed and merged things for C++20

  • Concepts - P0734r0
  • Explicit generic lambdas - P0428r2
  • ＿VA_OPT＿ - P0306r4
  • Default bit-field initializers - P0710r1
  • Fixed const-qualified pointers to members P0704r1
  • Allow [=, this] as a lambda capture - p0409r2
  • Designated Initializers - p0329r4
  • More deduction guides for the standard library - p0702r1
  • Endian - p0463r1
  • Arrays for make_shared - p0674r1

Gathered from r/cpp - 2017 Toronto ISO C++ Committee Discussion Thread (Concepts in C++20; Coroutines, Ranges and Networking TSes published)
(Thanks Yehezkel for reminding about that meeting!)

Added in Albuquerque, November 2017:  

  • operator<=> (aka the spaceship operator) and library support for operator<=> P0515
  • Range-based for with initializer P0614
  • Apply [[nodiscard]] to the standard library - P0600
  • std::osyncstream P0053
  • constexpr std::complex
  • constexpr algorithms P0202
  • Floating point std::atomics P0020
  • std::string/std::string_view .starts_with() and .ends_with() P0457

Gathered from 2017 Albuquerque ISO C++ Committee Reddit Trip Report : r/cpp

Another C++20 meeting, Jacksonville, March, 2018:  

  • Make typename optional in more places
  • [[likely]] , [[unlikely]] and [[no_unique_address]] - attributes
  • <version> header
  • Calender and timezone library - big and nice addition to STL - P0355
  • syncstream manipulators for C++ Synchronized Buffered Ostream
  • span P0122
  • [Pack expansion in lambda init-capture: ...args = std::move(args)](){} P0780

More info: 2018 Jacksonville ISO C++ Committee Reddit Trip Report : cpp

June 2018, Rapperswil:  

  • Contracts P0380
  • Standard library concepts P0898
  • Class non type template parameters (NTTP)P0732
  • Feature test macros P0941
  • Conditional explicit P0892
  • Virtual calls in constant expressions P1064
  • atomic_ref P0019
  • shift_left and shift_right algorithms P0769
  • type_identity P0887
  • ispow2, ceil2, floor2, log2p1 P0556
  • bit_cast P0476
  • Remove facilities deprecated in C++17 P0619

Gathered from r/cpp: 2018 Rapperswil ISO C++ Committee Trip Report

Added in San Diego, November 2018:  

  • Ranges! - P0896
  • void foo(Concept auto x)- style terse syntax for concepts - P1141.
  • consteval functions - P1073
  • std::is_constant_evaluated - P0595
  • constexpr elements:
    • union - P1330
    • try and catch - P1002
    • dynamic_cast and typeid - P1327
    • std::pointer_traits.
    • Miscellaneous constexpr library bits.
  • Signed integers are two’s complement - P1236
  • char8_t - P0482
  • Nested inline namespaces - P1094
  • Heterogeneous lookup for unordered containers P0919

Additionally, during this meeting, the Committee agreed on a single plan for modules, so there’s a higher chance we’ll see them in C++20.

Gathered from r/cpp: 2018 San Diego ISO C++ Committee Trip Report and Trip Report: C++ Standards Meeting in San Diego, November 2018 | There’s Waldo!

Added in Kona, February 2019:  

  • Modules - P1103!
  • Coroutines - N4736!
  • Extending structured bindings to be more like variable declarations - P1091R3
  • std::polymorphic_allocator<> - P0339
  • std::midpoint and std::lerp - P0811
  • std::execution::unseq execution policy P1001
  • std::ssize free function that returns a signed size - P1227
  • Precalculated hash values in lookup - P0920

Parallelism TS v2 was also published as ISO/IEC TS 19570:2018 - Programming Languages – Technical Specification for C++ Extensions for Parallelism.

Gathered from r/cpp: 2019-02 Kona ISO C++ Committee Trip Report and Trip report: Winter ISO C++ standards meeting (Kona) – Sutter’s Mill

Other trip reports:

Cologne Meeting & Your Voice  

Today (Monday 15th July) the Cologne Meeting has started. There are over 300 papers proposed so the Committee has a lot of to discuss!

A few days ago Herb Sutter created a poll that hopefully will help to add your voice into the prioritization of the proposals.

Have a look: Your “top five” ISO C++ feature proposalsl

Herb Sutter also published another blog post with a FAQ of the current standardization process. That’s a great way to learn about why we have 3-year cycle, why C++20 is much bigger than C++17 and C++14 and what’s the overall plan.

Draft FAQ: Why does the C++ standard ship every three years?

Upcoming Meetings  

The next meeting will also take place in Europe, this time in Belfast in November 2019.. and then in Prague Spring next year.

You can always find the list of ISO meetings here:
Upcoming Meetings, Past Meetings: Standard C++

Awesome Papers  

The papers (mailings) for the upcoming Cologne meeting can be found under the following link:
JTC1/SC22/WG21 - mailing2019-06.

or in a easier-to read form:

Below you can find my list of papers that brought my attention. The papers might still not be in merged C++20!. Those are not big features like Modules, Ranges, Networking… but rather some smaller items that should also simplify the language and help in our daily tasks.

P0323 std::expected  

P0323

The initial proposal for this feature was send 5 years ago, later the whole idea was a bit abandoned (without any clear reason). But now the work has been restated with the plan that we might get that into C++20.

The helper type would give us another way of reporting errors, and would be an improvement over returning “bool” or error code from functions… For example:

Error codes and output parameter:

MathError safe_divide(int i,int j, int& outVal) {
    if(j == 0) return MathError::divide_by_zero;
    if(i%j !=0) return MathError::not_integer_division;
    outVal = i/j;
    return MathError::OK;
}

With Optional:

std::optional<int> safe_divide(int i,int j) {
    if(j == 0) return std::nullopt;
    if(i%j !=0) return std::nullopt;
    return i/j;
}

As you see the version with optional doesn’t use the output parameter, but we lose the full information about the error. This can improve with expected:

expected<int, error_condition> safe_divide(int i,int j) {
    if(j == 0) return make_unexpected(arithmetic_errc::divide_by_zero);
    if(i%j !=0) return make_unexpected(arithmetic_errc::not_integer_division);

    return i / j;
}

You can read about the rationale in the earlier version of the paper, for example V1: P0323R1.

One doubt: we have several ways of reporting errors. Is having another method good or will just make our code more complicated and confusing to use?

P0881R5 - A Proposal to add stacktrace library  

P0881R5

This feature is based on a boost library: Boost.Stacktrace 1.0 - 1.70.0 and, as name suggests allows to gather information about the stack frames at runtime.

This might be helpful in environments where setting up debuggers is hard and also enhance log messages. For example when an error happens you can also attach the stack information. That will simplify the diagnostics.

P1152R3 - Deprecating volatile (added into C++20!)  

P1152R3

One of the dark corners of C++ is probably how to use volatile properly. The authors of the proposals make a bold suggestion on how to remove this concept from C++ so it doesn’t bother programmers in common code, but still leave it for some specific cases.

The ful rationale is nicely explained in the early version of the paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html

For example the proposal suggests:

  • keeping the volatile for load and store of variables
  • disallow to mark member functions as volatile
  • Deprecate (and eventually remove) partial template specializations involving volatile
  • Deprecate (and eventually remove) const as well as volatile return values

I think it might be a good approach to make the language easier without the need to know advanced concepts.

This change might break existing code, thus it might take us some time to properly add that into the Standard.

Update: This paper was merged into C++20 during the Cologne Meeting! :)

P1222R2 - A Standard flat_set  

P1222

A new type of containers in the Standard Library. As you might already know std::set, std::map (and their multi counterparts) are node based containers. They usually form a binary tree and then insertion, find and other operations work on that tree.

However, an alternative solution for set is to have a sorted vector of objects. Such approach changes the performance characteristics of the container and has several advantages: especially the cache locality (a vector is contiguous in memory) and less memory consumption. This is especially important for embedded environments, or games or performance critical apps.

The downsides: possibly slower insertion and removal time (as we need to sort the vector again after insertion/removal) and we cannot store non-copyable elements inside.

A really nice summary can be found in boost: Non-standard containers - 1.70.0 - flat_set.

More motivation and scope can be found in the early version of the paper: P1222R0

P1708R0: Simple Statistical Functions  

P1708R0

New and common stats functions for the Standard Library! The proposal wants to add the following functions into the <numerics> header:

  • mean​,
  • ​median​,
  • ​mode​,
  • population_stddev​,
  • ​sample_stddev​,
  • ​population_var
  • ​sample_var

For example:

std::vector<​int​> v{1, 2, 3, 4, 5, 6};
double ​m1 = std::mean(v.begin(), v.end());
std::cout << "mean: " << m1 << '\n'; // mean: 3.5

The statistics functions are pure additions to the library, so I don’t see any issues in having them. I wonder if there will be a version with ranges so that you can call std::mean(myRange).

Summary  

C++20 is getting closer and closer. I hope that during the Cologne meeting will have consensus over the major features and we’ll have time to fix bugs on time.

In the article, I wanted to show the current list of items in C++20 and also mention some interesting papers that brought my attention.

What’s your top five?