Trip report: Winter ISO C++ standards meeting

On March 5, the ISO C++ committee completed its winter meeting in Jacksonville, FL, USA. We had record-tying attendance, with over 110 experts officially representing eight national bodies. As usual, we met for six days Monday through Saturday, and around the clock from 8:30am till 10pm most days, after which many people still went back to hang out in the lobby or their rooms to update papers. — The hotel had a baby grand piano outside the main meeting room lobby, and so late at night you could often walk by and find one of several committee members playing a tune, while as usual people collaborated on their proposals, perched on couches and tables clustered around glowing rectangles, incanting standardese to the soft strains of Russian folk ballads and arena rock.

Here’s a summary of what happened, with some details about the current ISO C++ process so you can see just how the work is progressing and getting released. I’ve tried to add some links to the relevant feature design papers, or to the papers that summarize what was done which in turn usually carry more links to the design papers.

Note: The features listed below are those approved for C++17 at this meeting only. Previous meetings added other features that are already in the working draft.

What we did: Merging into C++17

This meeting was a major milestone in two ways.

First, we largely completed choosing the target set of features the committee felt were ready for C++17. Some had their specification wording adopted last week into the working draft for the C++ international standard (IS), and a few more are targeted to be adopted at our next meeting in June in Oulu, Finland, following which C++17 is intended to be sent out for its major international comment ballot.

Second, and perhaps even more importantly, we had the first merge of the new Technical Specification (TS) “beta feature branches” into the C++ international standard “trunk.” The committee considered five candidates, and adopted the first four as ready for C++17, with reports from implementers and users that the features were baked and unlikely to need future breaking design changes. The criteria for whether the committee thinks a given feature is ready to merge will vary by feature; this time, the committee ended up merging all the ones that had been completed and in beta testing for a year or more.

The four accepted branches merged into C++17 were:

  • The Parallelism TS, a.k.a. “Parallel STL.” This includes parallelized versions of most STL algorithms, which get a new execution policy where you can opt into running them in parallel on multiple cores and/or on multiple vector lanes—hardware that is now ubiquitous in the mainstream, as most medium- and high-end smartphones are both multicore and have vector units built in. For example, C++17 now allows: for_each(std::par, first, last, [](auto& x){ process(x); });.
  • The Library Fundamentals 1 TS (most parts), adding a new round of library components for C++17 including any, optional, string_view, shared_ptr for arrays, memory pools, search and sampling algorithms, and more. (An example of “more”: Have you ever wanted to pass a tuple that contains a function call’s argument list and expand it into the individual arguments? Now you can, using built-in standard functionality.)
  • The File System TS, which allows portable handling of files, paths, symbolic links, and more.
  • The Mathematical Special Functions IS, which was originally part of the first Library TR back in the 2000s and has now finally gained approval to be added to the standard for C++17.

We also voted the following other features directly into C++17 without going through a TS beta first:

  • Lambdas are now allowed inside constexpr functions.
  • Lambdas can now capture a copy of *this object by value, using the notation [*this]. It also works in combination with default capture, so [=, *this] is also allowed.
  • The range-for loop can now deal with generalized ranges where the “end” type is different from the “begin” type, such as sentinel-based and counted ranges, which will work well with the Ranges TS work.
  • The [[fallthrough]] attribute lets you designate that you are intentionally letting a switch’s case block fall through to the next block without a break.
  • The [[nodiscard]] attribute lets you annotate a return value to say that it should not be ignored by the caller, or annotate a type to apply to all uses of that type as a returned value. Canonical examples include the return value of std::async where ignoring the return value would mean being not async at all, and the return value of a container’s empty() function where people sometimes confuse empty() and clear() and we don’t want them to think calling empty() has side effects if they call it by mistake.
  • The [[maybe_unused]] attribute lets you annotate an intentionally unused variable or parameter.
  • Various other minor improvements and fixes.

Evolution also approved the following features that were not voted in at this meeting, but are currently on track for possible approval for C++17 at our next meeting in June for inclusion in the C++17 international comment ballot (note the links are to the pre-meeting paper versions; for example, in the paper that proposed constexpr_if the committee changed the syntax to if constexpr at the meeting):

A few more, such as structured bindings, might make it too but have not yet received Evolution design approval, so we’ll see in June if there’s support in Evolution and Core to call them ready.

C++17 will change the way we write C++ code, just as C++11 and C++14 did. For example, string_view and optional are expected to be heavily used in writing interfaces. And with parallel STL often you can just add std::par or std::par_vec, and your algorithm will speed up by a factor of 2-4 on ordinary hardware; we had a compelling story with C++11 move semantics where we could say “just recompile your code and it’ll often be noticeably faster,” and this is likely to be an even bigger improvement.

Other progress

We also made significant progress on other work, including that we now have opened five TSes to launch our next round of beta feature branches, most of which we expect to be sent out for their “debutante” international comment ballots in the next handful of meetings:

  • Ranges, Networking, Library Fundamentals 2, and Parallelism 2: We approved creating these at our last meeting, and officially adopted the first working drafts for all four of these TSes at this meeting. These form the “first four” nucleus of the next round of TSes to be developed by the committee and are now being officially specified in detail.
  • Modules: Recall that at the last meeting we reached design agreement to start work on Modules. At this meeting, we approved the initial wording to officially start active work on a Modules specification as a TS. That brings us to five active TSes in this second round.

And there are more to come:

  • Coroutines: These are being targeted for a new TS (possibly Concurrency 2 or their own TS) so that we have additional time to finish investigating an alternative proposal. I expect this to settle out within another couple of years and then make progress in some form (either the current proposal, or the alternative one if it pans out equally well, or possibly both) into the following C++ standard.
  • Concurrency 2: The concurrency group reports that they hope to launch a second Concurrency TS later this year at the Issaquah meeting. This might include coroutines as above. It might include features like synchronic, and there is still hope that the group might yet get design agreement on executors (a way to control where to execute work, such as where to run a parallel task, or where to execute a callback or continuation); if so, it would naturally go into the second Concurrency TS.
  • 2D Graphics: The 2D Graphics proposal that specifies a portable C++ library to wrap the Cairo C API has progressed to design and wording review. It’s big, so it will take a couple of meetings to process it, but it’s looking good that we could get an initial TS draft started this year.

At this meeting we also reached a design agreement on contracts, so that we now think we have a design that the competing proposers agree on and that the committee as a whole likes, and we hope to get initial draft specification wording later this year if this trend continues. Once we see the work, the committee can decide on a preferred target vehicle (TS or straight into the IS).

The committee also continued to spend time at the meeting incubating other work, including reflection APIs.

The main surprise last week was that the “part 1” unified call syntax proposal made it to full committee but we there discovered that there wasn’t yet consensus to adopt it. The authors (Bjarne Stroustrup and myself with the help of a number of experts) are continuing to work between meetings to see if consensus can be achieved by the June meeting.

Finally, we retired a TS that was not completed: We ended up not getting consensus on the experimental material intended for the Arrays TS, so last week we made the decision to retire that one.

Status of concepts and modules

Here are some specific notes about two particular TSes that everyone agrees are important and game-changing for how we will write C++ code: Concepts and modules.

Concepts was published as a TS less than a year ago, with the first production compiler implementation to ship soon as part of GCC 6.0. Despite its relative newness and lack of field experience, the committee seriously considered adopting it already for C++17 at this meeting. It was right on the edge: There was already a strong minority who felt it was ready to add to C++17, and a modest majority preferred to wait another year or two and get more experience with shipping implementations and field use of the feature.

Virtually everyone who spoke praised the feature as important, and either ready or getting close to ready, for adopting into the C++ standard. The only major distinction of opinion was whether or not they supported putting it specifically in C++17; those who spoke against that generally expressed that this feature was so important that we want to be sure we get it right and approve it once we have more experience using it in real world users’ code. My impression is that concepts is now one of the strongest feature candidates moving along well in the pipeline and adoption in the trunk IS working draft post-C++17.

At the October meeting, modules for the first time achieved a design consensus in the Evolution working group (EWG), with a “phase 1” that everyone agreed on and a “phase 2” that could be added. The most notable part of “phase 2” is determining whether and how to allow a module to carry and export macros. In October, EWG decided to aim modules for a TS covering “phase 1” and asked the proposers to come back with detailed specification wording, which they did for this meeting.

Last week, the whole committee voted to start a TS project and turn that document into the first working draft. Here’s a subtle but important note: This milestone of “create an initial working draft” is important, but usually not all that impactful to the community. The reason this one is different, and is actually very important to users, is that we knew that there are likely two major vendor implementation efforts waiting to start work on implementing support for modules in major compilers, but who were waiting until there was some draft specification that had been approved as a basis for development by the committee. We knew that having “at least an initial working draft” was a sufficient bar for the implementers to get started, and so despite our heavy workload this week focusing on C++17-targeted items (which this is not), I asked the Core working group to make a special effort to prioritize getting this project to this stage because we knew it would unblock new implementation efforts. We are very pleased to see this succeed, and look forward to active work beginning soon on more implementations of modules in several major compilers.

The pipeline

There are members who are very disappointed that we didn’t include more in C++17, especially concepts which was very close. To understand where we’re at, consider the following snapshot of our current “trunk” and “beta feature branches” status, shown in the context of three eras of C++ standardization laid side by side: C++9x, C++0x, and C++1x.


The C++ international standard (IS) is the “trunk” containing everything that is formally part of C++. Every time it is published, we have a new official international legal specification for C++.

A Technical Specification (TS) is a “beta feature branch” shipped as a separate published document. The contents of a TS are the committee’s best guess at what C++ users need, with a lower confidence bar on that guess because it is a “beta” and we do get a chance to make corrections before setting it in stone in the standard. In 2015, we completed our first round of six published major TSes, and are launching a second round.

This is a turning point: We just finished filling the pipeline, and this meeting saw the first merge from the beta branches. The disappointment came from that some would have liked to merge another branch or two. The good news is that, those branches are already shipped beta specifications that vendors can implement—in fact, most of them already have at least one supported implementation in a production compiler or library product. The branches that did not quite land in time to merge for C++17 can be expected to merge early in the next cycle—and in the meantime we’re still shipping the “trunk” and its ready features too. Now that the pipeline is full, we can expect features to leave the pipeline and merge regularly at high quality, which is essential with over four million C++ users worldwide relying on our work.


  • Each bar starts at the meeting where the detailed specification work officially began (usually “adopt initial draft”) and ends at the meeting that technical work was completed (usually “start final ballot / send for publication”).
  • Arrowheads join the IS at the meeting at which a TS feature branch was merged into the IS trunk.
  • In the current decade, the smaller boxes show full ISO C++ meetings—sometimes two per year, sometimes three per year—and highlights the meetings where we launch a C++ CD (ISO comment ballot, light blue) or DIS (ISO approval ballot, dark blue).
  • I’ve omitted the 1998-2001 hiatus because no new features were under active development in that period. The committee was voluntarily taking a break, and also catching up with C++98 bug reports while compilers caught up with the standard.

From “what” to “when”: C++0x to C++1x

During C++0x, the best and most solid parts of C++0x were the parts that shipped first as “beta” in the Library Extensions TR. That’s the model we’ve now embraced as the norm, rather than as the exception.

C++0x followed the “what” or “feature” model: We picked “what” features were in the standard and released whenever they turned out to be ready. That means we giving up on being able to predict “when” we’d ship, and even while C++0x was repeatedly delayed and the “0x is hex” jokes started, we released nothing in the standard the meantime; even features that had been approved into the C++ draft standard in 2004 had to wait until 2011 before they appeared in an official final standard. C++11 was a good release, but we underestimated “when” it would be ready by as much as five years.

C++1x follows the “when” or “train” model: We’re picking “when” to release the standard regularly, currently every three years, and including whatever features are ready. This still allows big long-pole features to be worked on; they’re just worked on concurrently until ready to merge. I’m pleased that the committee seems to be generally quite happy with the result. In Jacksonville, several experts came up to me to say that they had noticed how we had shipped more work in six years than in any other six-year period in the history of ISO C++. This would not be possible without the committee’s help and support; thank you again, everyone!

Although the train model has benefits, any model is also a tradeoff. The train model means we can’t slip a few meetings to try to “squeak in” another feature, and in fact we didn’t ship everything we hoped to ship in C++17, notably concepts… but neither did we at the same point in the C++0x cycle, in 2007. Now as in 2007, we are at a point where we have some good new features ready to ship in the standard, and at the same time we have several large desirable features in flight that are “almost but not quite” ready yet. In 2007, items on the edge or “just over the horizon” included work like threads and C++0x concepts, and in 2016 they include concepts “lite” and ranges. In both cases, those features are actually 3-4 years away (whether we knew it then or not). The difference is that in 2016, we’re shipping what is ready while still continuing development at full speed on the others.

Also, we initially thought a train model would let us alternate “minor” and “major” releases. The idea was that C++14 could be a “minor” release, and C++17 a “major” release. What actually happened was that we learned the pipeline+train model leads to regular “medium” releases as the pipeline moves at a steady pace and we regularly release what’s ready. As it turns out, C++14 was more than a fine-tuning release; it included powerful features like generic lambdas. Conversely, C++17 won’t be a “major release” on the scale of C++11, but neither could it be because C++11 took nine years to develop.

Never before in the history of C++ has the standard maintained such high specification quality, never before has it released on a regular predictable schedule… and as we removed that quality and schedule uncertainty, it’s no accident that never before have all the major compilers tracked the standard so closely, which benefits the whole worldwide C++ community.

How to define “progress”: Being unblocked to move to the next stage

How do we know we’re making progress? There is a tendency to emphasize “what features ship in,” a specific version; this was the committee’s mental model during C++0x.

In C++1x, the key is to keep the pipeline moving. What I monitor is that that major proposals are unblocked so the proposers can do work toward the next stage between meetings. As long as each proposal is not blocked, it’s moving forward toward the IS and “what ships in” will take care of itself as soon as it’s baked and ready.

Take a few minutes to read The life of an ISO proposal: From “cool idea” to “international standard.” Here are how some major work moved along at this meeting, in the context of those Stages:

  • Ranges, Networking, Library Fundamentals 3, and Parallelism 2: Stage 6 -> 7. All of these reached Stage 6 at our last meeting, and reached Stage 7 at this meeting. They’re all moving, and they’re well along in their development cycles and getting ready to debut in their international TS comment ballots in the near future.
  • Modules: Stage 3 -> 6. This reached Stage 3 at our previous meeting in November, and is already at Stage 6 at this meeting—that’s very rapid progress in one meeting!
  • Contracts: Stage 2 -> 3. This was stalled for a long time in Stage 2, and thanks to lots of work by the proposers (brokered personally by Bjarne Stroustrup) at the last meeting in November and then between meetings, it finally broke the logjam and reached Stage 3 at this meeting. Now it’s finally unblocked and on track again.
  • Coroutines, and 2D Graphics: Stage 3. These have both been at Stage 3 for a couple of meetings, and should reach Stages 4 and 5 over the next meeting or three.

If we focus primarily on each proposal moving incrementally to Stage N+1 and identifying and removing impediments, getting great new work in each new release of the standard becomes very nearly automatic.

What’s next

Our next meeting is this June in Oulu, Finland, where we plan to send a feature-complete C++17 out for its major international comment ballot. After that, we’ll address ballot comments at the November 2016 and February-March 2017 meetings and plan to send C++17 out for its final approval ballot then.

What’s after C++17? The default is to continue on the 3-year cycle (aim for C++20 then C++23), but we’re also thinking about whether to try out going to a 2-year cycle (aim for C++19, and if that works then C++21 and C++23). We’ll discuss that later this year as we see how C++17 and current/future TS plans are coming together, and should have more definite plans to report in a meeting or two.

Thank you again to the over 110 experts at Jacksonville last week, and the many more who participate in standardization through their national bodies, without whose efforts and willing collaborative spirit these results would not be achievable. The over four million C++ users worldwide benefit, and appreciate it very much too. Thank you, all, for your many contributions to Standard C++.


Thank you to everyone who provided input data and/or review of drafts of this trip report, including but not limited to: JF Bastien, Steve Clamage, Marshall Clow, Gabriel Dos Reis, William M. (Mike) Miller, Nathan Myers, Clark Nelson, Gor Nishanov, Peter Sommerlad, John Spicer, Bjarne Stroustrup, Ville Voutilainen, Jonathan Wakely, Nathan Wilson, and Jeffrey Yasskin.

31 thoughts on “Trip report: Winter ISO C++ standards meeting

  1. Huge THANK YOU! To you Herb, to everyone on the standards committee, to everyone in the TSes, and so on!!!
    C++ is finally becoming what it always should have been and far more! Making chaining work properly – finally – omg – finally defining a coherent ordering for such things, and making overloads use the same ordering as the operator they’re overloading?!!!! Are you kidding me! NIRVANA! So many wonderful things here, and so much dedication by all of you. I can’t express my appreciation adequately. :D

  2. pair p(2, 5); instead of pair<int,double> p(2, 4.5), wouldn’t the type of first variable be deduced to pair&ltint, int&gt? Example seems a bit misleading.

  3. @Adam: The best place to find some stories is to search for “trip reports” on, which often include stories and would give you specific people to contact individually to ask for more.

    Ah, good point: Normally I do write auto& on parallel algorithm invocations, now fixed. Thanks. (Because each parallel invocation is on a different element of the range, there’s no data race assuming the elements don’t share state further down under the covers, and so no reason to copy the elements, plus this allows updating the element in-place and works with noncopyable types.)

  4. By the way did you intend:

    for_each(std::par, first, last, [](auto& x){ process(x); }) // with auto&

  5. Hi,
    please forgive me for going completely off topic. I am preparing a talk on “[Features of] Modern C++” for my colleagues. I have the features under control but…

    C++ had (apparently) been in a standstill for some considerable time before it suddenly took a huge leap. I would like to include a short section on the propelling motivations and forces, that got things moving. With you as one of those forces, I would greatly appreciate some hints on where to find stories (even if anecdotal) that I could refer to. Many thanks!

    Kind Regards

  6. What about Arrays TS? Does it mean that this feature was completely dropped out or it needs some huge rework that would be better shipped with a new TS?

  7. It’s good to see 2D graphics entering the standardization process. Another important feature I really wish to see in a future standard is an easy API for reading & writing the popular web file formats, both ascii & binary (e.g. html, json, jpg, mp3, flv, pdf, etc.). I think the lack of such APIs is a major obstacle to the adoption of C++ in web & data mining applications, along with the lack of standard http & database APIs.

  8. Herb, Thanks for an excellent meeting report that goes a long way toward demystifying the current standardization process.

    My comment has do to with release cadence. As someone who has been using C++ professionally for over 25 years, I remember clearly the Bad Old Days when the language evolution was excruciatingly slow. The expectations around language rate of change of many professional engineers of my generation were formed during this period. Most of them, now in management positions, have not adjusted to the idea of even a three-year cycle, never mind a two-year. In the East Coast technology job market, it remains very difficult to hire smart engineers that have sufficiently deep understanding of C++. The number that have any significant understanding of ‘modern’ C++ is vanishingly small. In job descriptions that come through my inbox, I am still not seeing any mention of C++11/14 skills. Yes, some companies are making the switch, and it appears that the change is being driven from of bottom up. Even so, from what I am hearing from my network in Boston, the switch to C++11 remains a tough sell. In cross-platform environments, the foot-dragging at MSFT VS organization is uniquely unhelpful. But the adoption hurdle also has a lot to do with resistance to new concepts in an ‘ain’t broke, don’t fix it’ mindset. This resistance seems particularly strong in organizations, such as those in defense and other ‘hard’ engineering sectors, that have traditionally used C++ for performance reasons. A year and a half out, I’ve yet to hear of a single company fully embracing C++14.

    So, while I personally would love to see a two-year cycle, I don’t know that it would be helpful to the overall usefulness of C++.

  9. @Joe: You can see the parts of LibFund1 that were adopted at the linked paper. Basically, everything except a couple of things that hadn’t been implemented yet, in particular the invocation traits which require compiler support and are still awaiting an implementation to get experience (experience with both implementing it, and then with using it once it’s in a compiler for people to try out).

    @Yupei: Inline variables got design approval in EWG and is awaiting the authors to bring specification wording to Core for review. Looking at the Jacksonville Core notes, it looks like they noted they are still expecting it and I think they’re planning to look at the wording at our next meeting in June.

    @mbw: I occasionally see a suggestion for ‘restrict’ but it’s not obvious to everyone that C chose the right semantics and that the feature carries its weight — and if it were done in C++ it would require a bit more detail because C++ has more features to integrate it with.

  10. Looking forward to the additions, it kind of feels like christmas is coming.

    If I remember correctly, c++11 did not add a “restrict” qualifier because there were uncertainties on how it should be treated in combination with lambda closures. Is it in the realm of the possible that we might see this kind of feature in the upcoming standard? Please think of us poor number crunchers out there!

  11. Can we have a short operator/syntax for


    ? Then we won’t need to uglify the code with prefixes and suffixes like




    … whatever everyone uses?

  12. Which parts of Library Fundamentals 1 were not included in C++17 and why? Were the committee decide that the features needed more work, or did they think that features were a mistake and didn’t deserve to be standardized at all?

  13. @Markus: Thanks for the suggestions! We’ve pondered using something like Discourse. Re Concepts, it’s is in Stage 11 — a published TS “beta feature branch” that’s nearly ready to merge and repeat Stages 6-10 in the IS “trunk” itself.

    @feeded: I wasn’t sure if anyone was using the blog categories so I stopped adding them a year or two ago. Now that you’ve noticed, I’ve gone back and added the “C++” tag to this and other posts. :)

    @Timothy: Not that I know of. Personally I’m a big fan of multiple languages and language design, and while I’m sure committee members are aware of other languages, I think the committee is doing the right thing: Moving C++ itself ahead to stay current with its bread-and-butter goal of being a portable close-to-the-metal language that gives you rich abstractions that are also very efficient. It is very easy to be distracted by chasing perceived competitors instead of keeping one’s eyes on one’s own ball.

  14. Herb, what do you think about Rust? Is competition from Rust driving C++17?

  15. What happened to post categories on this blog? I’m subscribed to the ‘C++’ category RSS feed and now I see I’ve missed lots of C++-related posts because for some reason they are ‘Uncategorized’ and thus not present in the feed…

  16. Module and package system is going to be a breakthrough.(

    #package ...

    ) And they are doing this respecting backwards compatibility in every regard. If only C also adopted a compatible module system. Java, CLR, Python, and D has this.

  17. > `path` defines implicit conversion to `string` and thus can be used in every case where string is currently used, including fstream constructors. (The corresponding note mentions exactly this use case).

    Not good enough. One of the good things about `path` is that it can encode Unicode paths. The goal would be the ability to do this:

    fs::path pth = …; //Get a path with possible Unicode characters.
    std::ofstream strm(pth);

    That won’t work with an implicit conversion to `std::string`. At least, not on Windows. The Windows version of iostreams cannot use UTF-8 paths. The only APIs that can take the full set of Unicode strings use 16-bit `wchar_t`-based strings.

    `path` gives us a way to make this platform-independent. We can use UTF-8 strings, feed them into `path`, and if the implementation needs to convert it into UTF-16, so be it. And vice-versa.

    The problem is opening a file with it. Implicit conversion to `std::string` will not help, for the above reason. Even implicit conversion to `basic_string` won’t work, because `std::ofstream` cannot take a `std::wstring`. It only takes `char*` and `const string&`.

    This needs to be standardized.

    Also, we need versions of fopen that will take `path` as well. More people use the C file IO than the C++ file IO, particularly in production code.

  18. Thank you for this detailed overview and explanation of the current way of working!
    It all seems to be a lot more work than is visible from the outside.
    Thus, also many thanks to you experts bringing in those new features and ensuring the quality of future C++.

    However, having read other trip reports and reddit discussions I’m wondering what is meant by often mentioned more experience and user feedback. I feel the barrier to express simple positive feedback on a proposal or experimental implementation to be quite high. Writing an email to the authors with a complaint or bug report appears much more likely to happen.
    Have you considered something like a stackoverflow/github site for C++ proposals? That would give many of us average programmers the possibility to easily comment on and, possibly more importantly, up-vote or down-vote both a proposal and other comments. In particular for controversial features such direct positive and negative user feedback might help getting faster to an agreement. Or, it might bring up the need for other features not yet considered necessary. Also, perhaps more people would volunteer and start working on or testing experimental implementations, in particular in those early stages.

    Finally, at which of the 11 stages would the Concepts TS be currently?

  19. I think in context of the “when” over “what” attitude of C++14 and C++17, it makes sense to seriously consider a 2-year cadence. There is a lot of disappointment (AFAICT) over what did *not* ship in C++17, but that’s because now we have to wait 3 years at minimum to see those omissions in an IS. This is especially disappointing when hearing that a feature like Concepts was very nearly ready *now*. Switching to a 2-year cadence may make each release less impressive, but it will soften the blow to users anticipating certain features that don’t make it and possibly reduce pressure to shoehorn things into each IS if it’s “close enough”.

    Though, starting a 2-year release cadence on an odd-numbered year makes me cringe inside.

  20. @jmckesson Looking at the linked (pre-meeting) versions (I have no idea what if anything have changed while merging to the standard):

    1. `path` defines implicit conversion to `string` and thus can be used in every case where string is currently used, including fstream constructors. (The corresponding note mentions exactly this use case).
    2. There is not conversion from `path` to `string_view`.
    3. `path` already has a tepmlated constructor from a range, which accepts a string_view.

  21. @petke: Concurrency 1 was only just completed at the last meeting, so it was a little too early to propose merging it into trunk, as the trunk is close to shutting down to stabilize and ship C++17.

    @jmckesson: I believe people are busily writing papers on how to apply string_view throughout the standard library. The committee felt that shouldn’t be gating factor to ship string_view itself, which is well understood and can deliver value to user code today even as the standard library works on potentially adding it pervasively as a separate step.

    @farid: That’s the basic idea, in particular to have left-to-right evaluation for everything except assignment which naturally flows right to left. Check out the link to the paper for details.

  22. About Order of Evaluation:
    Are we going to have expressions evaluated regarding associativity and precedence rules of combining operands with operators (because that is IMHO the naturally expected behavior)?


  23. I’m glad to see many of the Library TS features go into the standard, as well as the FileSystem TS.

    My biggest question is about system’s integration: what is being done to actually incorporate these new library elements within the rest of the standard library?

    For example, FileSystem TS defines a path type. But *nothing* actually uses it directly. Not `std::fstream`, not `fopen`, not one single standard library file processing function takes it. Will `string_view` overloads be added for `std::stoi` and its ilk?

    And what of combinations of such elements? Will `path` allow you to get a `string_view` of its contents? Will `path` be constructible from a `basic_string_view`, just as it is from a `basic_string`?

    These TS’s are all designed to be stand-alone. But once they become a part of the standard, then they need to work well with each other. We really need different parts of the standard library to work well together.

  24. Thanks for the trip report. I have been refreshing this page for a week in anticipation :)

    What is the status of the “Concurrency 1 TS” though? It seems to me some features there are low risk, widely useful, and has a number of mature implementations.

    I’m thinking of the std::future improvements. Especially the “then” continuations and the heterogeneous “when_any” would make std::future much more useful. Are these not mature enough to be split out of the TS and be shipped in C++17? There are many years of of experience with using them in PPL (+power pack), TBB, HPX, etc. Is there any issues holding this back for another 3 years?

Comments are closed.