Earlier this year I attended the WG21 C++ standards committee meeting in Jacksonville, Florida, and as usual I spent most of my time in the Library and Library Evolution Working Groups. You can read about some of the other groups' work in Jason's Core report and Torvald's Parallelism & Concurrency report.
As Jason wrote, several of the Technical Specifications published in the last few years were proposed for inclusion into the next revision of the C++ standard (C++17) and most of them added new features to the Standard Library. That meant that the Library Working Group spent much of the week doing careful review of those large documents, to ensure that what was added to the standard was correctly specified and that it was coherent with the rest of the library. This blog summarizes some of the significant changes from this meeting.
The Mathematical Special Functions IS (ISO/IEC 29124:2010) was included in C++17 almost unchanged, and is already supported in GCC 6.
The Filesystem TS (ISO/IEC TS 18822:2015) was included with some minor changes. The most important one in my opinion was relaxing the requirements on the filesystem::path::iterator type to allow more efficient implementations. That change was made in response to a defect report I filed after I discovered there was no way to implement the original requirements efficiently, and that neither of the existing implementations (Boost.Filesystem and Visual Studio's "TR2" implementation) met those requirements. GCC's experimental::filesystem::path::iterator does meet the full requirements, but I'm glad that I can simplify the code and make it more efficient for the C++17 implementation that will be coming to GCC soon.
The majority of the Library Fundamentals TS (ISO/IEC TS 19568:2015) was merged into C++17, with two exceptions. The invocation type traits were not included, because they have not been implemented in any compiler (they are library traits, but require assistance from the compiler to give the correct answer). One of the purposes of a TS is to gain implementation and user experience, so they won't move from the TS to the standard until that happens. The other part of the TS that didn't make it to C++17 is the section defining type-erased allocators. They were an attempt to fix some problems with how allocators are used in some parts of the Standard Library, by using the new polymorphic memory resources defined in the TS. That would have been an ABI-breaking change for questionable benefit, and so was not added to C++17. The majority of the memory resources features from the TS are in C++17, just not the type-erased allocator parts, and C++17 will include all the other good stuff from the TS including the string_view, optional and any utilities.
One significant change was made to the Library Fundamentals features that were included, which fixed a recently-discovered problem with the interface of the "searchers" concept introduced in the TS. The C++17 interface returns a pair of iterators rather than a single iterator, to handle the case where the pattern being searched for does not have a fixed-length (for example, if the searcher uses a regular expression to match the pattern). Returning two iterators allows returning both the start and end of the substring that was found by the searcher. This was a good example of the TS giving us additional experience so that a design mistake could be found and fixed before it was included in the C++ standard.
Discussions continued in Jacksonville regarding the discriminated union type, variant. It's still coming but it currently looks like it will be included in the next revision of the Library Fundamentals TS rather than in C++17.
Other additions to the C++17 library approved in Jacksonville include:
std::clamp, an algorithm to 'clamp' a value between two boundary values.- New type traits
std::is_swappable,is_nothrow_swappable, and
std::is_callable. std::not_fn, a generalized "negator" that comes from the second version of the Library Fundamentals and allows us to deprecate the much less flexiblestd::not1andstd::not2from the original STL.- An overload of
std::string::data()which returns a non-constchar*, which is a more expressive way to get access to a string's characters than&str.front()or&str[0](and unlike those alternatives, is valid even when the string is empty).
