Current Proposals for C++17

published at 25.02.2016 10:53 by Jens Weller
Save to Instapaper Pocket

There is a new batch of proposals for C++17, published for next weeks ISO C++ Committee meeting in Jacksonville, Florida. With way over 100 proposals, and limited time, I will try to cover in this posting only papers which have C++17 in their title, which gives a fairly random selection with a few highlights. A first overview gives you my listing by c++ committee subgroups or the original ISO listing at open-std.org. Currently C++17 is still in the making, each committee meeting will set new trends and add features likely to the standard. But lets have a look at some of the proposals. I'll go by the order of my subgroup listing.

Core - Removing Deprecated Exception Specifications from C++17

This paper is about removing a language feature, which was deprecated in C++11: exception specifications. Quote:

Exception specifications were added as part of the original design of the exception language feature. However, the experience of using them was less than desired, with the general consensus by the time the 1998 standard was published being, generally, to not use them.

Well, very successful feature it seems. This paper now seeks to remove the exception specification from the language, but to keep throw() deprecated, and make it an alias of noexcept(true).

Library - Adopt not_fn from Library Fundamentals 2 for C++17

This paper proposes to deprecate/remove the not1 and not2 binders, by introducing not_fn from Library Fundamentals 2 in C++17. So this is an interesting paper, the quoted Library Fundamentals 2 is a Technical Specification, which contains a few interesting features proposed for the standard library. The goal of this paper is now, to move not_fn from the TS into the C++17 standard. This would then allow, to fully deprecate the old binder API, which is already a legacy part of the STL. The authors argue, that there is enough experience through boost, to justify moving not_fn into C++17. Also it would allow a clear path for deprecating and removing fully the old binder APIs from the Standard Library.

Library - Adding a subsection for concurrent random number generation in C++17

The with C++11 introduced <random> header introduces a set of pseudo random number generators. This proposal aims at adding better support for concurrency into C++17. The PRNG has an inner state, which changes when it generates a number, so the generating method cannot be const. This implies that it is not safe to use the same generator over multiple threads.

The goal of this paper is now, that the standard specifies this in a note, that concurrent access to a standard PRNG is not thread safe, and mention possible solutions (one PRNG per thread, as locking will slow down the PRNG more the running it in serial). It is an interesting paper, focusing only on one minor section of the standard. Yet I am not sure if one should start adding notes to everything not thread safe in the standard...

Library Evolution - C++17 should refer to C11 instead of C99

Which version of C should C++17 refer to? C99 is the currently the C Standard which defines the subset of C and C++, at least from the C++ Standards view point. This paper seeks to make this C11, which brings a few more new things into C. The newly introduced headers with C11 are already covered by other parts in C++, so that there will not be C++ headers added for C11 headers argues the paper. A conflict between C11 and current C++ is thread local storage, as the keywords differ. Other pitfalls could be the interoperability of threads or atomics in a mixed C / C++ program. So, one can see, that C and C++ start to differentiate in the details of newly added features.

The official C11 keyword is _Thread_local, while C++11 defines thread_local as a keyword. Still, names _A-Z... are reserved for the standard in C++ too. Also C11 has a define thread_local pointing at the keyword.

Library Evolution - Deprecating Vestigial Library Parts in C++17

More deprecation (and possible removal in the future! \o/).

This paper aims at deprecating:

• std::iterator class (an interface meant to aid you at implementing your own iterators)
• value_compare predicates (this impacts only map and multimap)
• algorithms taking half an input range
  • all algorithms taking a full range and a third iterator to a second input range are meant, e.g. std::mismatch(it1:begin,it1:end,it2:begin) -> std::mismatch(it1:begin,it1:end,it2:begin,it2:end), output iterators (e.g. std::copy) are not affected!
• redundant members of std::allocator
  • remove duplicate behavior in allocators, now often covered by std::allocator_traits or allocator<T>::address by std::addressof.

The paper lists further candidates reconsidered for deprecation:

• vector<bool>
• is_literal trait
• temporary buffer APIs
• raw_storage_iterators

Overall an interesting collection of Standard Library features which are now superseeded by newer Standard Library features. Also, it shows that the committee is willing to not only add things, but also to deprecate, and remove and break things in the future. Which is great, yet the impact of this paper should be minimal on most C++ bases.

Library & Filesystem - Adopt File System TS for C++17

So after a long history, <filesystem> is finally proposed to be a part of the C++ Standard. Currently there are already 3 shipping implementations, and a soon-to-be shipping 4th implemenation. The TS should have finalized a stable API for handling file system queries in C++. Its origin has <filesystem> in boost::filesystem, which is also an alternative if you want to use filesystem today in C++03 to C++14. A first overview on boost::filesystem can give you my blog entry "Handling files - using boost::filesystem".

Library & Library Evolution - Adopt Library Fundamentals TS for C++17

Adding the Library Fundamentals TS to C++17. Surely a good idea, adding a lot of functionality to the standard.

The highlights:

• searchers (boyer_moore and boyer_moore_horspool)
• std::optional
• std::any
• std::string_view
• std::polymorphic_allocator (and a lot more additions to <memory>
• search & sample additions for <algorithm>

This would make C++17 a lot better!

Library & Library Evolution - Mathematical Special Functions for C++17, v4

Adding special mathematical functions to <cmath>. This proposal is in the 4th version, its aim is to include an international standard part of the C++ Language.

Transactional Memory - SG5 is NOT proposing Transactional Memory for C++17

There is progress on Transactional Memory, but its not far enough to include it in the standard yet. Quoting:

SG5 feels that the Transactional Memory Technical Specification should not be standardized yet because there needs to be more user experience. The principal purpose of a TS is to gather implementation experience and usage, which can happen only when the implementation has had enough time for users to use it and to give feedback.

WG21 - Concepts in C++17

Adding the Concepts TS to C++17, this would be one of the major features of C++17. With GCC 6.0 a first implementation of the Concepts TS will ship in a major compiler, yet it has been available in a branch since 2013, so there is experience in using concepts in libraries like sqlpp and other libraries, even an implementation of the Ranges TS exists. Also initial implementation has begun in Clang, so when C++17 ships, there should be at least two compilers offering support.

The paper quotes the advantages of the current Concepts approach from the users view:

• better (template) error messages
• better/simpler notation
• overloading
• better documentation

Also, other libraries and TS build upon concepts, namely Eric Nieblers work on Ranges depends on this. So it would be possible to have a Concepts based Standard library as an TS with the release of C++17. There are two other proposals about concepts, one pro one contra adding it to the C++17 standard:

• Why I want Concepts, and why I want them sooner rather than later - Ville Voutilainen

• Why I want Concepts, but why they should come later rather than sooner - Matt Calabrese

This is a hot topic, and if Concepts is added, the next standard will clearly have to make additions. Yet waiting for the next standard could limit the evolution of C++ and post pone many things which are based on the idea of concepts, such as Eric Nieblers Range library.

Two of the contra arguments are:

• Is it good to add Concepts without a concepts supported Standard Library
• "the current specification likely rules out us ever getting the checking of constrained template definitions in the language"

The first argument can be also seen in the opposite: that we should add Concepts to the Standard before applying it to the Standard Library. It also shows that concepts is a very deep change for C++, it will improve things, but together with Ranges also change C++ as we know it.

The second argument is much more concerning, can and should concepts provide checking of constrained template definitions?

It will be interesting to see, which side wins, after all shipping Concepts as a TS would make it available, but details could be changed later, when more user experience exists. As GCC 6.0 is not released, there is currently no compiler offering support for this feature. In my opinion it would be nice to have Concepts in C++17, yet a TS should always have the time to gather user experience, so that changes still can be made. I think, that the next half year until the fall meeting will decide if C++17 has Concepts or not.

I've made this the topic of a poll on twitter, and even Eric Niebler is surprised, how many want to add Concepts to C++17, it is a very popular feature:

@meetingcpp No released compiler implements Concepts, so our usage experience with it is zero. I'm surprised so many are ready to ship it.

— Eric Niebler (@ericniebler) 25. Februar 2016

Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!