Frequent readers of this blog know that over the past year, I’ve been working on a modern range library suitable for standardization, integrating good ideas from hither and thither — particularly from Sean Parent and Andrew Sutton — resulting in a library that’s available immediately, and a proposal to the standardization committee. This week I presented my work to the C++ Committee Meeting in Urbana-Champaign. The ensuing the discussion has implications for the future of the Standard Library.

Ranges Evening Session

I presented my ranges work on Wednesday evening to about 60 committee members. I’m happy to report that it was very warmly received. The committee liked the design of my ranges library and wants to see it in a standard ASAP. The feeling of the group was that the changes were big enough that they wanted them in a separate document known as a TS or a Technical Specification rather than in the official C++ standard. That way, we can flush out potential problems before baking it.

Some people might be disappointed that ranges will not be in C++17, but let me assure you that this is a Very Good Thing. Vendors have been proactive about implementing and shipping TS’s quickly, and there’s a chance we might get ranges into users’ hands more quickly this way. It also means that since we’re targeting a TS, we can be far more ambitious. Had we tried to squeeze this into C++17, we would have had to gut the proposal and standardize a very small, very conservative subset of functionality. By going the TS route, we can get much more cool stuff out the door much faster, and ship incremental updates as they become ready.

If any part of the Ranges TS looks especially promising and noncontroversial, it can be air-lifted into C++17.

The Future of the Standard Library

With the dawn of Concepts Lite as a language feature, the next obvious step is to use the feature to improve the Standard Library. During the ranges discussion, it seemed generally accepted that it will be impossible (or at least very undesirable) to add concepts to the library in a way that doesn’t break somebody’s code. The committee hates to break working code. One possibility would be to ship a new version of the library alongside the old. Users could then migrate at their leisure. That possibility was openly discussed to much head-nodding.

If that happens, we would be free to make changes to the Standard Library, not only to leverage Concepts Lite but also to support ranges, increase uniformity and expressive power, ease-of-use, safety, and to fix some long-standing issues. Whatever we end up with would look a lot like the current Standard Library, and of course existing code would continue to work.

Let me emphasize that this is my opinion of the general feeling in the room. The committee has not voted on this. What is clear is that work will now begin on a version of the STL that uses Concepts Lite and that looks a lot like my range-v3 library, and that this version will not make a priority of perfect backwards compatibility. That work will go into a Technical Specification, and vendors will start shipping it in a std::experimental namespace as soon as it hits the presses. I couldn’t be more excited!

Edited to clarify what is my opinion and what is a possible future.