Trip report: Fall 2015 ISO C++ standards meeting

Taking polls during the Friday afternoon plenary session — the room is hotter than it looks

Yesterday we just wrapped up our fall ISO C++ committee meeting in Kona, HI, USA. We normally meet in windowless rooms all week, but because of the committee’s current size we had to use the hotel’s largest space which was open-air (though technically still windowless).

It was a busy week. During the days from 8:00am-5:00pm, usually six sessions ran concurrently: Core (CWG), Evolution (EWG), Library (LWG), Library Evolution (LEWG), Concurrency (SG1), and usually at least one more subgroup such as Numerics. In the evenings, from 7:30-10:00pm, there were more evening sessions than evenings, and sometimes three would run concurrently. Daily sessions started at 8:00am, and most of us attended the evening sessions until 10:00pm each day, after which many people still went back to their rooms to update papers until midnight. (This schedule is pretty usual for ISO C++ meetings.)

What we did

We approved a number of actions — see STL’s great Reddit post for a summary, and some details on the library parts. Here are a few more notes from my own perspective.

First, actual major deliverables:

Concepts TS: It’s published! We did that between meetings, but it’s worth mentioning again here. There was initial discussion about putting it directly into C++17; we expect to seriously consider that at our next meeting.

Concurrency TS: We approved the final Concurrency TS for publication. It’s done!

Parallelism TS: The Concurrency group decided to pursue airlifting version 1 of this TS (which has already been published) into the draft for C++17, and we expect to see that proposed to the full committee at our next meeting. This week, we went ahead and also approved starting official work on version 2 of the Parallelism TS.

Ranges TS: We approved starting official work on a Ranges TS based on Eric Niebler’s great working text. The goal is to send it out for its main ballot in March following our next meeting.

Networking TS: We approved starting official work on a Networking TS based on Chris Kohlhoff’s excellent wording, evolved from his Boost.ASIO library.

Next, other major work:

Modules has reached a milestone: design agreement! This was done by separating “phase 1” and “phase 2” of modules, and greenlighting phase 1 to proceed to wordsmithing for adoption (hopefully at our next meeting) into a new Modules TS, while in parallel continuing work on an expanded phase 2 which can follow.

Variant has reached a milestone: design agreement! This consumed our main Monday evening session. For the first time, the broader set of committee members agreed on its design and we expect to see (and hopefully approve) actual wording at our next meeting. Its initial target will likely be Library Fundamentals v2. (Spoiler for those following along at home: It’s the same variant that LEWG approved at our last meeting in Lenexa, but after an exception renders the variant invalid, attempting to access the invalid variant causes defined behavior, such as throwing an exception, instead of undefined behavior. This was acceptable to three major constituencies: people who wanted a zero-overhead variant, people who wanted a variant without an omnipresent empty state, and people who wanted a variant without undefined behavior.)

Contracts seem to have made a breakthrough in getting the various parties to agree on the nitty-gritty details of a design. This consumed two three-hour evening sessions on Tuesday and Wednesday nights. If this holds, we expect to see a combined proposal that for the first time achieves broad agreement in time for our next meeting.

Reflection continues to make slow but steady progress. Chandler Carruth reminded us that several initial proposals have already started progressing through the committee.

There’s more, but those are some of the highlights.

Next meetings

Our next meetings (always listed here) will be Jacksonville, FL, USA on Feb 29 – Mar 5, 2016 and Oulu, Finland on Jun 20-25, 2016. Note that the Oulu meeting is when we plan to feature-complete C++17 and send it out for its main comment ballot, so that will be a big meeting. (It will also be within a few dozen kilometers of the Arctic Circle and is deliberately scheduled so that the summer solstice occurs during the meeting, so the joke is that there will likely again be lots of post-dinner sessions in Oulu, but for once we can guarantee there will be no evening sessions!)

9 thoughts on “Trip report: Fall 2015 ISO C++ standards meeting

  1. I was looking at P0144, the structured bindings proposal. I was thinking that a great extension to this would be allowing the user to unbind a template parameter pack:

    auto func(Args …args)
    auto {x, y, z} = args…;
    auto {u, v, w} = modifier(args)…; //Can unpack over arbitrary expressions.

    This would be exceptionally useful in template code. If there are more arguments in the binding than the parameter pack, you get a compile error. But if there are more arguments in the pack than the binding, their expressions are evaluated, but are simply discarded as if they were returned from a function without being used (so [[nodiscard]] will still complain).

  2. For variant, eg

    variant<int, string>

    note that functions like


    already needed to check if the discriminant was an int. And throw if it was a string. Now it throws if it is a string or invalid. So no extra code. And visitation needs to check the discriminant as well, so no real extra code there either.
    As for “separate tag value for invalid state internally”, assume the variant has uses an int (or enum) as the discriminant of which type is currently set (ie 0 means int, 1 means string for the above variant). -1 can mean invalid.

  3. Does it mean there will be a separate tag value for “invalid” state internally?

  4. @jmckesson: “Modules phase 1” is essentially Gaby’s approach, and “phase 2” is essentially adding support for exporting macros. As for variant, “zero overhead” means at run time — no extra space consumed, and no extra code executed — compared to writing it (correctly) by hand using a raw union and a discriminant tag.

  5. jmckesson, why check it? If the variant invariants’ are not met, chance’s are your function doesn’t know enough to act accordingly, and should just let it throw.

  6. > Modules has reached a milestone: design agreement! This was done by separating “phase 1” and “phase 2” of modules

    What are the two phases exactly? Is “phase 1” going to be what Gabriel Dos Reis presented at CppCon2015? Because if we get that, I’m not sure what could happen in “phase 2”. And if “phase 1” doesn’t include all of those elements, I don’t know how useful that phase could be.

    > attempting to access the invalid variant causes defined behavior, such as throwing an exception, instead of undefined behavior.

    Does this not mean that every function that uses the variant must check its validity? How exactly is that “zero overhead”?

    Granted, I don’t care all that much, as long as we have a never-empty variant that can get through the committee…

Comments are closed.