Issaquah meeting trip report

This November I visited the C++ Standards Committee meeting in Issaquah and decided to write a blog post about it.

The complete list of submitted proposals is presented in the pre-Issaquah mailing. As you can see, this list contains over 100 papers.

I spent most of the week with the Evolution Working Group (EWG) and a couple of days with the Library Evolution Working Group (LEWG). More information about the structure of the committee is available here.

I’ll start with the work of EWG, i.e. proposals for the core language.

We discussed the bitfield initializer proposal P0187R1. The committee is in favor of the most natural syntax for such initializers:

int x : 5 = 42;

I’m glad that EWG decided to get rid of the quirks in the original proposal. However the new syntax does have its problems:

int y : true ? 1 : a = 42;

= 42 is an initializer, not a part of ternary operator. The grammar will need some disambiguation rules. Chandler found an interesting bug in GCC related to bitfield width (or rather, constant-expressions in general) parsing.

The committee continues to explore the design space of compiler-generated comparison operators. Walter E Brown presented his proposal P0436R0 which would allow the compiler to convert, say, x != y into !(x == y) and x > y into y < x (if the latter is provided by user, but the former isn’t). I really like this proposal. In future it can be extended to generate, say operator-> in terms of operator*, but even in its current variant it will save us from writing lots of boilerplate code. Unfortunately, the proposal as-is did not satisfy the committee (hopefully, either Walter or someone else will eventually fix it). The two other proposals that were presented are P0481R0 and P0432R0. The major concern of the committee is whether or not any comparisons should be generated by default. The opt-in comparisons get more consensus than the default ones. We also discussed the idea of introducing the three-way comparison (a.k.a spaceship) operator into C++. Microsoft and Google folks seem to be in favor of it, but no formal proposal exists yet. Lawrence Crowl proposes to add three-way comparisons as a library function in P0474R0, he told me that he is also in favor of the operator, but decided to stick with the library approach, because it is easier to push through the committee.

I presented my proposal P0412R0 on benchmarking primitives (slides are available here). It adds some facilities to avoid interference with certain compiler optimizations when performing microbenchmarking. The committee was in favor of the proposal and encouraged me to continue work in that direction. Another proposal in performance area is P0479R0, which discusses likely and unlikely attributes (it tries to standardize an analog of a well-known GCC intrinsic __builtin_expect). It was suggested to put these attributes on arbitrary statements rather than conditions of if statements.

Louis Dionne, the author of Boost.Hana metaprogramming library presented several proposals. P0428R0 will make generic lambdas even more generic. For example, it will allow us to write:

auto f = []<typename T>(std::vector<T> vector) {
// ...
};

This syntax was originally present in GCC’s implementation of generic lambdas (before they were standardized).

P0315R0 will allow to use lambdas in unevaluated contexts (e.g., in decltype). The committee was in favor both of these proposals.

Paper P0424R0 proposes a feature which would allow us to use string literals as non-type template parameters. This proposal was rejected because of compilation performance concerns. Louis provides some details on std-discussions forum.

A 40-page proposal P0465R0 presents some ideas on how C++ code can be annotated to facilitate formal verification of program correctness. It largely overlaps with the contracts proposal P0380R1, but has some new ideas (e.g., how to specify function postconditions in presence of unhandled exceptions). One major drawback of this proposal is that it is very far from being complete and lacks details necessary for implementation. It would be nice if the author of P0465 directed her efforts at enhancing the contracts proposal.

Gor Nishanov’s coroutines (gorroutines :) ) proposal P0057R6 was presented to CWG. As you might notice, it’s already the sixth revision. There is also some implementation experience (in Clang and MSVC), so it looks like we will soon get the Coroutines Technical Specfication. Nevertheless, some folks are not satisfied with the current approach. P0444R0 expresses their concerns. The author of this paper and Torvald Riegel think that the standard should also support stackful coroutines (P0057 coroutines are stackless), and that it would be nice to somehow unify syntax of both kinds of coroutines to facilitate code reuse.

Static reflection proposals (wording: P0194R2 and rationale: P0385R1) are finally ready for review by EWG and LEWG at the next meeting. It’s a huge milestone for this proposal.

Library evolution working group spent most of the week discussing National Body comments (that is, mostly fixing bugs in upcoming C++17). 11 of these comments were dedicated to a new feature of C++17 called “template argument deduction guides” (proposal P0091R3). The idea expressed in this proposal is really nice: it will allow to deduce class templates arguments from constructor invocation:

std::tuple t(1, 'a');

In this example the type of t will be deduced to std::tuple<int, char>. Ideally, this will allow to get rid of std::make_tuple and other factory functions in the future. Proposal P0433R0 tries to make use of this new core language feature in the standard library. Indeed, using a new feature in such a big and complex library is a good test for the feature. Walter Brown even advocated for applying such policy for every new language feature.

Some smallish tweaks for C++17 were also accepted. Russian National Body representative Antony Polukhin presented his proposal P0426R0 to make char_traits fully constexpr. The effect of this proposal is that string_view will also become constexpr. Another accepted paper related to string_view is P0403R0, which adds literal suffixes for string_view. One will now be able to write:

// equivalent to string_view("Hello")
auto s = "Hello"sv;

Unfortunately, very little time was left for C++Next (i.e. likely C++20) proposals. Howard Hinnant presented P0463R0 which adds an enum class endian. As the name suggests, it has enumerators for endianness. Concretely, it defines endian::little, endian::big and endian::native (which is equal to either big or little on “sane” platforms). We will now have a portable way to detect endianness at compile time.

P0429R0 introduces a new container called flat_map. It’s an associative container based on sorted vector, which has much better traversal performance compared to map and unordered_map at the cost of linear-time insertions. It is a part of the Boost.Container library.

During the Saturday session I presented P0457R0 (slides are available here) — a proposal to add starts_with and ends_with methods to string and string_view that check whether a given string starts with (or ends with respectively) another given string or character. LEWG was in favor of the proposal and hopefully I’ll present it to LWG during the meeting in Toronto.

Another nice addition to C++Next is P0477R0 which adds a template class monostate_function which will allow us to convert any callable object (for example, a function pointer) into a function object suitable for use as a comparator or hash function. This will reduce the amount of boilerplate code in the following example:

struct custom_compare_t {
    bool operator()(int lhs, int rhs) const {
        return custom_compare(lhs, rhs);
    }
};
std::set<int, custom_compare_t> ints;

which can now be rewritten as

std::set<int, std::monostate_function<custom_compare>> ints;

To summarize, this meeting was largely devoted to fixes for C++17. The next meetings in Kona and Toronto will be more centered around C++Next.