Table of Contents

Following the pattern for other ISO C++ Meetings, I prepared a blog post where you’ll learn about:

  • The current status of C++20
  • an overview about the Belfast meeting (4th till 9th Nov)
  • a few interesting papers that are worth reading

Let’s start!

Disclaimer: the view presented here is mine and does not represent the opinion of the entire ISO C++ committee.

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(*).

(*) The C++20 is almost ready, but still we might see some changes.

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

Below you can find a list of meeting and features that were accepted or rejected during each session.

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)

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

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 (but see Cologne meeting later…)
  • 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

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!

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, July 2019  

  • Contracts moved out of C++20; Contracts Study Group created.
  • std::format("For C++{}", 20) -P0645
  • The C++20 Synchronization Library - P1135
  • constexpr allocation P0784
  • Making std::vector constexpr - P1004
  • Making std::string constexpr - P0980
  • Stop Token and Joining Thread - P0660
  • source_location - P1208
  • using enum - P1099
  • constinit - P1143
  • Math Constants (std::numbers::pi and friends) - P0631
  • Rename Concepts from PascalCase to snake_case �� - P1754
  • Deprecating volatile - P1152
  • Layout-compatibility and pointer-interconvertibility Traits - P0466
  • [[nodiscard]] for constructors - P1771
  • Improved iterator concept hierarchy - P1207
  • Move-only views - P1456
  • Additional views and range adaptors - P1035
  • Integrate operator<=> into the standard library - P1614
  • Bit operations - P0553
  • Permit trivial default initialization in constexpr contexts - P1331
  • Extensions for class template argument deduction - P1021

Gathered from this r/cpp thread.

Trip reports:

The Belfast Meeting  

Today - 4th November 2019 - another ISO C++ meeting is about to start (in a few minutes?). This time the committee gathers in Belfast, Northern Ireland.

The main topic of this meeting is to address the first round of National Body comments for the C++20 draft (from Cologne). We probably won’t see any new features added into the draft, as the Standard is in the feature freeze mode. Mostly we’ll focus on stabilising the existing elements.

If time allows the committee will discuss papers that target C++23 and beyond.

Upcoming Meetings  

It seems that the committee likes Europe now, and the next meeting (Spring 2020) will take place in Prague (Czech Republic). Then we’ll travel to Varna (Bulgaria) for the hopefully first session that will add features into the working draft of C++23.

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

Awesome Papers  

The papers (mailings) for meeting “Pre-Belfast” can be found under the following link:
JTC1/SC22/WG21 - mailing2019-10.

or in a easier-to read form:

Below you can find my list of papers that brought my attention. I try to select not huge documents, but something smaller… however this time I couldn’t resist and look at some more significant things.

I’m also looking forward to getting your opinion and your selected papers.

Let’s start with something relatively small, a nice addition to the std::filesystem component:

P1882R0 Addition of a filter to recursive_directory_iterator  


To iterate through directories in C++17 you can use directory_iterator or the recursive version. Hovewer, they don’t support filtering. One way to reject unwanted path is to write a custom filtering code. For example:

std::vector<fs::path> paths;
fs::path inPath = /* ... */;
std::filesystem::recursive_directory_iterator dirpos{ inPath };
std::copy_if(begin(dirpos), end(dirpos), std::back_inserter(paths),
    [](const fs::directory_entry& entry) {
        return check entry object here;

In the above code, we use copy_if, and then there’s a lambda that filters out directory entries objects. In this sample, I store the final paths into a separate vector.

Since filtering is a handy thing, the author proposes to have direct filter support inside the directory_iterator. That way you could pass a filter lambda (with some options) straight into the iterator:

auto filter = [](const char * filename) { 
    const char* ext = get_filename_ext(filename); 
    return strcmp(ext,".c") == 0 || 
           strcmp(ext,".h") == 0 || 
           strcmp(ext,".cpp") == 0 || strcmp(ext,".hpp") == 0;
for (auto &entry : fs::recursive_directory_iterator(folder, filter, fs::entry_restriction::file))

You can even have a look at the benchmark where the author compares the current solution, with the regex version and the proposal (with lambda filter).

Is that something useful? Or maybe it’s better to keep the design separate? I wonder how we could build such an example with ranges and views?

I want to leave you with the answers and now move to some other feature that might be very handy and modernises older techniques.

P1729R1 Text Parsing  

P1729R1 - Text Parsing

In C++20 we’ll have the formatting library: adapted from fmt library. It’s like bringing the Python formatting code and good old printf style into the modern C++.

We can follow that path and for C++23 add the parsing part! It means modernising sscanf functionality.

For example:

std::string key;
int value;
std::scan("answer = 42", "{} = {}", key, value);

There’s also an interesting observation.

According to [CODESEARCH], a C and C++ codesearch engine based on the ACTCD19 dataset, there are 389,848 calls to sprintf and 87,815 calls to sscanf at the time of writing. So although formatted input functions are less popular than their output counterparts, they are still widely used.

It’s still an early stage for this paper, but I think it would be good to go into that direction and have a common interface for handling string parsing and formatting, also, with the inclusion of std::chrono stuff.

Do you often use parsing routines? Would you like to see that in the standard?

OK, let’s now move on to a bit bigger element:

P1108R4 web_view  

P1108R4 - web_view

That concept seems huge! It means that the library will give you a simple interface to create and manage a compact web browser! You’ll be able to write HTML, javascript and hook your C++ callbacks.

While the whole idea seems strange, I actually like the core approach for this entire paper:


it’s hard to do the graphics and UI right (and maybe audio), so why not embrace other existing standards (the web stack) and provide an interface to work with it? This will allow us to learn C++ with some nicer examples.

The library will be totally optional, so no need to implement such complex web stack on some restricted embedded environment :)

But maybe it would give us a nice way to show more cool examples out of the box, rather than just using std::cout? Or maybe we need to accept that C++ is not going into any of these directions and we should just stick to preferred third-party libraries? (like QT, WebKit or native system APIs)?

You can also follow the live discussion at r/cpp

So far, I mentioned three features that you might use at some point in your code, but now I’d like to show not a feature but rather a useful resource for learning C++:

P1705R1 Enumerating Core Undefined Behavior  


In short, the paper proposes two things:

  • create an annex in the Standard that would list all the undefined behaviour cases
  • create TR that would expand the annex, show more examples and provide a better description

I think that might be a super valuable thing to have! As the author wrote, it’s hard to go through 1700 pages of the current standard and look for the “undefined” word. It’s much easier to have a list as a good reference.

Then we can build on that and create more examples (in the TR) and learn more. Right now it’s not easy to know all the tricks in the area of Undefined behaviour, and it’s definitely not what average C++ developers are aware of.

And now we can go into more high-level discussions. A director for C++23:

P0592R3 - Plan for C++23  

P0592R3 - To boldly suggest an overall plan for C++23

It looks like the direction for C++ is as follows:

  • Library support for coroutines
  • Executors
  • Networking
  • A modular standard library

In other words, we try to embrace what we have in C++20 and then improve the overall standard. Especially the library support for modules, coroutines.

And if time allows we’ll have also:

  • Reflection
  • Pattern matching
  • Contracts
  • plus tons of smaller features

Would you like to see more of the big things in the next Standard?


Through this article, I wanted to give you an overview of the C++20 status and also look ahead for some new things in the language and the library.

I’m happy to see what’s your top five. What are your favourite features that might be included in the next standard? or what direction should we take?