The Red Hat toolchain team was well-represented at the Fall 2014 meeting of the standardization committee (JTC1/SC22/WG21) in Urbana-Champaign, IL, USA. In this article, Jason Merrill summarizes the main highlights and developments of interest to Red Hat Enterprise Linux developers. Stay tuned for separate articles summarizing the library and concurrency working group aspects.
The fall meeting of WG21 (the C++ standardization committee) this year was hosted by the CS department at the University of Illinois at Urbana-Champaign. This was the first meeting after ratification of the C++14 standard, and we weren't changing the working paper while C++14 was out for voting ISO doesn't allow changes to the working paper while there's an open ballot, so there was a lot of leftover business from the last few meetings that was waiting to be voted on.
As usual, I spent the week in the Core Language Working Group. We spent the majority of the week reviewing papers for new language features.
About two days were spent on the Concepts proposal, hoping to get it in shape to vote out as a Public Draft Technical Specification at the end of the meeting, but it didn't make it; there were too many changes needed for them all to be taken care of during the week, even with me helping with the redrafting. We're planning to have a couple of teleconferences and then a Concepts face-to-face meeting in January to get it finished up in time to send it out and get public comments before the next meeting in May.
We also reviewed the Transactional Memory TS, which was ready for PDTS after a few revisions.
Smaller papers we reviewed, all but the last of which were voted into the working paper on Friday:
- A proposal to replace uncaught_exception, which returns bool, with uncaught_exceptions, which returns int.
- A proposal to add u8 character literals.
- A proposal to allow arbitrary constant-expressions as pointer, pointer-to-member, and reference template arguments.
- A proposal to allow attributes on namespaces and enumerators:
namespace [[deprecated]] A { } enum E { e1 [[deprecated]] };
- A proposal to simplify nested namespace definition:
namespace A::B::C { } - A proposal to call a T&& function parameter a "forwarding reference" to provide standard vocabulary for teachers and authors.
- A proposal to add "fold-expressions" as a form of pack expansion over a binary operator rather than just into a comma-separated list:
template <class... T> auto sum(T... t) { return (... + t); } - And finally, a first look at a library proposal to add a source_location class to encapsulate __LINE__, __FILE__ and __FUNCTION__ in a way that works better with default arguments. This one is still working its way through LWG.
We also spent a fair amount of time on issue processing. Many of the issues this week were related to alias templates; it turns out that the effect of various decisions has been that alias template specializations with dependent template arguments are equivalent to their expansion (so they compare as equal) but not functionally equivalent (because substituting into the dependent arguments might be different for SFINAE). Core is leaning toward making declarations that are equivalent but not functionally equivalent ill formed (no diagnostic required), just as the reverse already is.
There was also an issue about whether alias templates can be declared more than once; implementations currently differ on this point. We decided to allow it.
There was significant sentiment towards actually adding the noexcept-specification to the function type, after all these years of thinking that it would probably be a good idea but we weren't ready to deal with it. This was motivated in part by the transactional memory PDTS doing something very similar with the transaction-safe qualifiers. The exception-specifier has been part of the type in G++ (and, I think, several other implementations) all along.
There were evening sessions every day discussing Coroutines, Contracts, Ranges, Pattern Matching and Reflection. All of these are in early stages of working out exactly what functionality we will want.
The next full C++ meeting will be in early May in Lenexa, Kansas; between now and then there are the Concepts meeting and a Library Working Group meeting in Germany.
Thanks to Jason Merrill of Red Hat’s toolchain team for this summary.
Last updated: September 1, 2016