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.
Both the Networking TS and the Ranges TS successfully completed their only (PDTS) ballots before Kona. The only work that remains before finalizing those is to address their PDTS ballot comments, which will largely be done in LWG. LWG was fully booked all week long with C++17 CD comments, but on Saturday started processing the PDTS comments as well. We plan to finish resolving Networking and Ranges comments and finalize those TSes at our next meeting in July.
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.
Correction, 3/25: The original text did not reflect that LWG additionally spent a lot of time on Saturday processing Ranges PDTS issues. LWG did (thanks!), so we actually have a head start on those. As originally stated, we expect to complete the Ranges TS and Networking TS in July, and the Kona head start on PDTS comment resolution makes doing so that much easier.
Sutter’s Mill 
@maksym: UFC did not make it into C++17 but may be brought up again in the future especially once we have modules which could address some of the technical concerns people raised.
@steve: And don’t forget we also have the double-width and half-width byte types, std::overbyte and std::underbyte!
wow std:byte !!! it will change the life of millions of coders! thanks dude! Keep on making C++ the most bloated and complex language on the planet, copying concepts of others and implementing them in the most complex way!
Hello there!
What is the status of unified call syntax? (n4165 proposal)
Regarding the comparison proposal. I can see the following correspondences to mathematics: strong ordering = total order, weak ordering = total preorder, partial ordering = preorder, strong equality = equality, weak equality = equivalence. Out of these categories, the concept of mathematical partial ordering is actually missing: -1 = less, 0 = equal, 1 = greater. Naming the concept of a preorder a partial order in C++ can create confusion. Otherwise, great job with the proposal!
annotation to: tuples for ‘loop’
As this is not a runtime loop but a compile-time loop, analog to the ‘if constexpr’, it seems consistent to name this ‘for constexpr’.
@Aman: Sorry, but I’m not working on a book right now. In the meantime I recommend Stroustrup’s “A Tour of C++” to everyone for a nice short (180-page, can-read-in-a-plane-ride) tour of modern C++14. I don’t know whether he’s updating it for C++17 though.
@Brian: Yes, P0194 is the one that’s now started progressing into the main subgroups. Note that there are other complementary proposals that would make the usage syntax different, but the core “engine” is still the same.
@Mikeb and others: Thanks!
Congratulations. It seems like an astounding amount of work that goes into getting the standard out. I can’t even keep up, and all I’m trying to do is follow along.
Just curious about the std::byte specification and the usage of UTF8 string. Currently, many codes I see uses char string, eg. `std::string` which is basically an alias to `std::basic_string`. However given that each element of the string is not a character (UTF-8 character can be composed of 1, 2, 3 or 4 bytes), using std::string for utf-8 string might be incorrect.
Perhaps UTF8 string should be represented using a wrapper of byte array. I don’t know :/
Hi Herb,
I’m curious about what’s going on with reflection. Which proposal is **the** reflection proposal? Is it P0194R3?
Wasn’t there some disagreement about whether to allow cyclic module dependencies in the Modules TS? Are cyclic dependencies going to be allowed or disallowed, and why? They seem pretty useful.
Thank you for the update. And congratulations on getting C++17 done!
Can’t wait to try my hands on C++17.
Herb, are you also rolling out a book that I can buy it to get detailed C++17 features.
Did the group get to enjoy visiting the island?
Am so happy about this, cant wait to start using c++17
@Denis: The TM TS is complete. There has been no suggestion yet to start work on an extension/revision, or to merge it into the C++ IS.
@Leo: Both, and in vector lanes where supported in hardware when clauses were data-independent.
@Bender: It’ll be C++20, but note that C++20 work begins this summer and is expected to be feature-complete in just over 2 years (summer 2019).
@jmckesson: Right. Yes, both implicit generation and chaining can still be brought later as independent proposals. I don’t currently have a plan to propose them again myself, but maybe I will and if others want to they’re welcome to use the writeups of those features in my paper.
@Eric: Amended. Thanks for the reminder.
Actually, LWG make huge progress on Ranges TS issues processing as part of a marathon 8-hour session on Saturday. We approved 2 papers and the resolution for about 35 issues. It’s very close now.
> 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?
As
std::byteis 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-aliasingobsolete.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.
Very nice Sir
I think `std::apply` and `std::make_from_tuple` are specified wrong. They should be using `get`; not `std::get`.
Herb, did you work on TSs concurrently or in parallel? Just kidding, couldn’t resist :-)
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!