The ISO C++ committee had its winter meeting in Kona, HI, USA from February 27 to March 4, hosted by Plum Hall and the Standard C++ Foundation. Over 100 people attended, officially representing 9 countries.
C++17 is done!
The big news is that we completed C++17, which dominated the work of the meeting: C++17 is now technically finished and being sent out for its final ISO balloting. All that remains for C++17 now is some ISO red tape and minor touch-up to get it officially published, which is expected to be just mechanical.
There’s not much exciting to report from a “new features added at this meeting” point of view, because the main work was to finish resolving national body review comments on C++17 and ship the product. Perhaps the most exciting thing was that we decided to add the std::byte type; the rest of the work was final pre-release bug fixes before casting C++17 in stone, the important-but-unsung work of getting a product to ship quality.
Thank you very much to everyone who contributed in person or through papers, email, telecons and otherwise to creating and shipping C++17 — as well as several TSes that we also worked on concurrently and will soon be considering to add early in the C++20 cycle! Your hard work is much appreciated by everyone. I especially want to call out the Library working group (LWG) members, who had the heaviest C++17 workload in Kona and worked around the clock every day to finish responding to the comments in their areas. Thanks again, everyone. Here’s a group photo we took just outside our main meeting room (directly behind us) right after approving C++17:
Next, we’re already shifting gears to begin work on C++20 at our next meeting this July in Toronto.
Other progress
We also approved shipping the Coroutines TS out for its (expected-to-be-only) international comment ballot, aka PDTS (Proposed Draft Technical Specification).
We came oh-so-close to approve shipping the Modules TS out for PDTS as well. The Evolution working group (EWG) weighed in on whether a couple of final cases should be included before sending it out for comments, and we hope to finalize that feature set and send it out in July in Toronto.
We also did work on the Parallelism 2 TS, and on a number of pre-TS proposals including 2D Graphics. On a personal note, my comparisons proposal was positively reviewed by both EWG and the Library Evolution working group (LEWG) (only the core proposal was encouraged, none of the parts marked ‘optional’) and wouldn’t have got that far without standing on the shoulders of giants — the previous comparisons proposals listed in the paper, notably Bjarne Stroustrup’s efforts and again Jens Maurer’s writing the standardese wording for Bjarne and now for me — and the detailed comments of over two dozen reviewers many of whom did detailed reviews of multiple drafts (it was a busy winter) — thank you again to everyone who helped me with that, it is at least 2x better as a result. If people are interested, I might give a short talk about it at CppCon this fall.
The Reflection proposal has now progressed out of the incubator Study Group, and was presented to the main Evolution and Library Evolution subgroups for the first time. To handle related proposals, the Reflection Study Group’s charter is now being expanded to also include proposals toward a general first-class compile-time programming model. For anyone who loves the glorious compile-time magic that C++ template metaprogramming (TMP) is able to do, but wish it could both do much more and also not be template metaprogramming with angle brackets and inscrutable code and diagnostics, then you’ll love the work in this direction; think “constexpr on steroids.” I’m looking forward to seeing how this evolves.
Because we were busy shipping C++17, we didn’t get to start doing PDTS ballot comment resolution for the Networking TS and Ranges TS. However, those have successfully completed their only ballots, with relatively light comment volume that we’ll consider at our next meeting in July, and we hope to do that and potentially finalize them and send for publication this summer. (Some will ask: Why did we have time to work on some of these non-C++17 items above, but not these PDTS comments? It’s because the group that would have handled these comments is LWG, which was the group fully booked with C++17 work in Kona — C++17 took first priority.)
In EWG, we looked at some feedback on the Concepts TS with an eye toward hopefully merging the Concepts TS into the C++20 working paper early in the C++20 cycle — possibly as soon as this year. There was one design tweak that EWG approved, and a couple more that will likely be discussed again in July in Toronto.
Here is an updated snapshot of our status, also available on the status page:
Thank you again to the over 100 experts in Kona, and the many more who participate in standardization through their national bodies! Have a good spring… next stop: Toronto, to start C++20 this July.
Hi!
Are there any news on Transactional memory TS? It was done quite some time ago and nobody is talking about. Is it ok?
PS: Hooray!
Herb, did you work on TSs concurrently or in parallel? Just kidding, couldn’t resist :-)
I think `std::apply` and `std::make_from_tuple` are specified wrong. They should be using `get`; not `std::get`.
Very nice Sir
Herb please make it C++19, not 20… C++19 would still be a minor disaster since it would be 8 years from last major standard, but at least it would not be 9 like C++20 will be.
[…] standards meeting (Kona): C++17 is complete {$excerpt:n} submitted by /u/DerKuchen [link] [comments] Source: […]
[…] ORGANISATION FÜR STANDARDISIERUNG C++ requirements member Natural herb Sutter lately distributed his document from the requirements meeting plus told that will C++17 is currently […]
[…] report: Winter ISO C++ standards meeting (Kona), C++17 is complete https://herbsutter.com/2017/03/24/trip-report-winter-iso-c-standards-meeting-kona-c17-is-complete/ #cpp […]
[…] Source link […]
As
std::byte
is special version of enum that ignore aliasing it would be interesting if user could mark other types in same way. At least it would made-fno-strict-aliasing
obsolete.> only the core proposal was encouraged, none of the parts marked ‘optional’
So, no implicit generation of anything and no chained operators. I can live without implicit generation of “, given that explicit generation doesn’t require that I write a half-dozen functions or list all of my members.
On chained operators, was there any sense that they might be willing to accept it as a separate proposal?