C++17 content (a prediction)

C++17 content will likely close in the next 2 meetings. At the upcoming meeting in Jacksonville, it has already asked that any interested party who wants a major feature in C++17 to put in a position paper, or an opposition paper. We call this the land rush into C++17. Please see previous meeting blog from Lenexa for background.

What will happen is that at Jacksonville, this question will focus our work for the week, with the intention of voting out a Committee Draft(CD) at the following meeting in Oulu in June for National Body Comments. The CD stage is where most comments should happen. This is the national bodies’ first chance to inspect and provide feedback on the committee’s work. After the ballot ends, the comments are collected and the committee has to work through them and respond with a Disposition of Comments. This CD will return comment in the Issaquah meeting in Nov. If there are no major surprises, a DIS will be issued out of that meeting. This is unlikely to be that fast. There will likely be nontrivial changes, such that either we will take 2 meetings to address these comments or a 2^nd CD will be issued . With 2 meetings to address comments, the DIS will be issued at the latest in the Feb 2017 Kona meeting, which will result in approval vote in the July 2017 Toronto meeting. There is no need for a FDIS if the DIS passes cleanly. And all this has to happen cleanly such that the Standard appears for sale on ISO and National Standard body websites for sale just before the end of 2017.

C++17 already contains a large number of language and library features as a result of integrating changes from Evolution Working Group, and Library Evolution Working Group. Please see below for a current list of the features.

Language:

• static_assert(condition) without a message
• Allowing auto var{expr};
• Writing a template template parameter as template <…> typename Name
• Removing trigraphs
• Folding expressions
• std::uncaught_exceptions()
• Attributes for namespaces and enumerators
• Shorthand syntax for nested namespace definitions
• u8 character literals
• Allowing full constant expressions in non-type template parameters
• Removing the register keyword, while keeping it reserved for future use
• Removing operator++ for bool
• Making exception specifications part of the type system.
• __has_include(),
• Choosing an official name for what are commonly called “non-static data member initializers” or NSDMIs. The official name is “default member initializers”.
• A minor change to the semantics of inheriting constructors

Library:

• Removing some legacy library components
• Contiguous iterators
• Safe conversions in unique_ptr<T[]>
• Making std::reference_wrapper trivially copyable
• Cleaning up noexcept in containers
• Improved insertion interface for unique-key maps
• void_t alias template
• invoke function template
• Non-member size(), empty(), and data() functions
• Improvements to pair and tuple
• bool_constant
• shared_mutex
• Incomplete type support for standard containers
• Type traits variable templates.
• as_const()
• Removing deprecated iostreams aliases
• Making std::owner_less more flexible
• Polishing <chrono>
• Variadic lock_guard
• Logical type traits.

But few of them are wide-ranging in their effect on covering all of the programming domains of C++. They still add excellent value to a new Standard, but people are beginning to wonder if it will be as large a change as C++11, not to say that is necessarily a good thing to have that many large changes. Without the addition of something like Concepts or other major features that are broadly applicable to many domains, the two questions everyone has is will it contain any truly major features and if so will they be wide-ranging in their effect on the C++ community, i.e. be broadly applicable to all domains, as opposed to a few domains. The outlook, as they say, is stay tuned.

Cppreference gives a great link of all the current projects on hand.

http://en.cppreference.com/w/cpp/experimental

Of these I can form a similar table stating what is their current status just before the Jacksonville meeting, on their likelihood of making into C++17, as we now have much greater clarity and insight.

At the pre-meeting call which I and other senior leaders of the C++ committee participate, one of the first call was a planned discussion on the first day of plenary at Jacksonville of several major projects with the goal of using what precious time we have to focus on those that have a good chance of making it.

• FileSystems TS
• Parallelism TS1
• Library Fundamental TS1
• Concepts TS
• Special Math IS

These are the most likely candidates for C++17 that has been in existence as a TS, may have enough usage experience, and is of definite interest to some group.

Of these FileSystems TS and Parallelism TS will likely have the most amount of support to move forward, mostly intact, but you never know. LF TS1 will likely have some parts of it separated out according to the following table courtesy of Marshal Clow:

For Concepts, the main question is how important will be separate checking and whether there is no way forward for definition checking of templates. Is definition checking a big deal as it was one of the reason the original Concepts C++0x was pulled in the “Frankfurt Accord”? Will it take a long time to be added after current Concepts “Lite” constraint checking is added. I personally do not see definition checking as a big impediment, and if people want definition checking, it will be done. Waiting for it is the essence of Perfect is the enemy of Good, and Good in this case is good enough.

Special Math is interesting as it has been its own IS for sometime, and now is interested in being added to C++17. There is now much more High Performance Computing interest attending C++, so it is no longer a small domain. C++ has a real chance to be enabled for this important domain which covers not just nuclear research or astronomy, but oil and gas, and many consumer domains. It will be good for C++ to have this.

In order to move forward, there will be a three-way vote to decide on each of these questions to judge how many are firmly decided that this should be in, or not in C++17, and how many are still undecided, pending more work. This will lead to some item be dropped from consideration immediately if there is an overwhelming majority against it., to allow time for other more likely candidate to move ahead.

We already had a number of proposals in this and other areas put forward by SG14:

Kona trip report look back

The last time we were in Kailua-Kona for a C++ Standard meeting was just after C++11 was released, and we had successfully justified the requirement for a new Study Group SG5 Transactional Memory. We are now back in Kona again, always a favorite destination and sure to draw many more people to come to the Standard Meeting, and we have just completed publication of SG5’s Transactional Memory Technical Specification, and starting a new Study Group SG14 on Games Dev/Low Latency/Financial.

Kailua-Kona on the Big Island of Hawaii is in some sense trapped in time, as over the last fifteen years I have been coming here, it has barely changed. Most of the same shops are still in the same place. But the rest of the Big Island has changed (with new volcanic eruptions) and C++ is very different from when I first started coming here.

Today, C++ has 14 Study Groups, have over 100 people attending, and is being updated every five years or less. We are closing on the cutoff date for C++17 features which will likely be the next two meetings in 2016. After that, we will likely be drafting the final changes for ratification in time for C++17 publication, which can have a pipeline as long as eight months.

Over the last decade, the Canadian delegation has grown from just me to 10. At this meeting, there were so many Canadians attending that I would need to do a special Canadian count during formal country ISO votes. We had the following Subject Matter Experts from Canada:

• Michael Wong, ISOCPP.org, OpenMP CEO (HoD)
• Hubert Tong, IBM
• Tony Van Eerd, Christie Digital
• Botond Ballo, Mozilla
• JF Bastien, Google
• Patrice Roy, Sherbrooke Universite
• Eric Fiselier, Bloomberg
• Michael Park, pending
• Xing Xue, IBM
• Chris Cambly, IBM

Whereas before, I was the only trip report and covering multiple rooms, now some of them have written great trip reports and can help me to cover other rooms which are occurring simultaneously.

I mostly hang out in SG1 concurnecy where I co-chair some sessions while sometimes chairing my own SG5 Transactional Memory and SG14 Low Latency. I would attend Evolution, Library Evolution, Core, or Library sessions as needed to advance individual proposals.

For the first time, in French, Patrice Roy, a professor from Sherbrooke Universite has written this report:

http://h-deb.clg.qc.ca/Sujets/Orthogonal/wg21-2015-Kona.html

While Botond Ballo has continued in-depth coverage of the Evolution Committee but also an excellent general overview of the entire proceedings.

https://isocpp.org/blog/2015/11/trip-report-cpp-standards-meeting-in-kona-october-2015-botond-ballo

At this session, I worked to advance a number of proposals for SG14 which means unlike previously where I spent most of my time in SG1 Parallelism/Concurrency, I would move around between all the committees.You can see here for a SG14 paper status report out of Kona.

Description of the major projects

Given the many well done blogs on the content of these meetings, it seems most useful to focus for this blog what major features will get into C++17.

What will Definitely will be in C++17, essentially in nearly complete form

The Filesystems TS is the first major TS accomplished since TS started becoming the way Evolution Groups (Both Language and Library) explore major features without getting bogged down. This features enables a uniform way of accessing filesystems submerging the differences between Unix, and Windows (for example, the back vs forward slash, and awareness of capitalization). It has been a Boost library for quite some time under Beman Dawes and its addition to C++17 is certain. There will likely be a second version of this because as it stands it does not deal with filesystems such as Network filesystems, or that which exists on mainframe systems. These will likely be added in future TSs.

Parallelism TS will contain Parallel (and Parallel and vectorized versions) versions of STL. It has been published with many implementations and there is no reason to think it will have any changes on it for inclusion into C++17 fully as is. It contains the seed that will form the future of massive parallelism as we move forward to support accelerators.

Library Fundamental adds a number of useful functionalities in the form of optional, any, string_view and much more to the Library. It has been published and parts will certain to be in C++17. There will be controversial parts that would be left out.

What may make it into C++17, at least some part of it in some form.

Concepts (lite) TS is a constrained template mechanism that enables the template side to have a prototype mechanism to offer a much more useful template mechanism that finally solve the error novel problem whenever a template client does not match what the template requires. This has been a long standing problem in C++ that would have been solved with the original Concept proposal. But in Frankfurt back in 2007, it was shown that the existing design would mean even simple uses of template would require knowledge of Concepts. That was because it contains extensive template dfeinition checking as well as a Concept Map mechanism for abstraction of archetypes. That original Concepts proposal was removed in a critical vote, which will forever be known as the “Frankfurt Accord”, although few people know about that.

What will Not make it into C+17, but will be on deck for C++20 or C++22.

Concurrency TS contains improvements to futures, latches and barriers, and atomic smart pointers. Although there is implementation experience, it was just approved and is too fresh to be voted to be added to C++17. The futures improvement are language changes but are already in well tested in Microsoft’s Visual C++ and C# compilers. The other two features are library additions. Latches and barriers have been used in Google, and atomic smart pointers are just a syntactic sugar on top of smart pointers such that it has a first class name. In future, it will form the basis of a future marriage with the Parallelism TS to form the basis of the support for SG14’s design for Accelerator support for Massive parallelism. The future mechanism is ideal in conjunction with parallel STL to enable dependency with bulk dispatch.

Library Fundamental TS2 already contains a rich amount of content because the work is still ongoing. It already has source code information and various utilities. As this is being balloted by National Bodies, it will be approved before the deadline for C++17 cutoff in the next two meetings but is too fresh to be considered for C++17.

One of my two groups, the Transactional Memory TS has a well defined specification that has already been approved to publish. It will very soon have implementation in GNU V6 in 1H, 2016. We also have been exploring Wyatt Technology usage in industry and learning from their experience of using TM in their code. We still need more experience from usage of the TS form and GNU will give us that. Without that usage experience, SG5 volunterily does not proposed this to be added to C++17. Most likely, if any part is to be include, then the synchronized form of the construct is the most likely candidate. Unlike the atomic form, It enables a simple replacement for locks, that is composable (whereas locks do not compose) , and usable immediately in that it works with any current code (even transaction unsafe code). Of course, the downside is that it will become irrevocable as soon as a transaction unsafe action is performed, and will commit all of its actions. This makes it possible to be not well-scalable.

Networking TS is based on established practice in Boost’s ASIO library by Christopher Kohloff. It is a socket library and much of it was reviewed last year in a special Library meeting with current wording review in progress. It is a large proposal and as such, despite its well formed historical basis, some details has changed from the original Boost.ASIO. It will not make it into C+17.

Ranges TS has been called STL2, and instead of iterators will use range-based algorithms. It was specially commissioned by ISOCPP.org and designed by Eric Niebler, an expert long-time Boost developer. It is also design review complete with wording review in progress. It is a very large change enhancement and while there is wide interest and support behind it, it is still too fresh to make it into C++17.

Parallelism TS2 is already on the deck with major features such as Task blocks, agents, progress guarantees, and SIMD. In fact, a joint SG14/SG1 call last week just established SIMD in a form that essentially accepts implicit wavefront as the way to move forward, modulo a few semantics corner cases with multiple threads writing to the same SIMD lane, causing either undefined or well defined industry behavior (ordered by whichever writes last). At some point in the future, this TS may also add mapreduce and pipeline capabilities.

Numerics TS (SG6) is still under development with additions for Fixed point arithmetic, DFP, and future support for IEE754 128-bit floating point. It has been meeting on and off as the chair cannot attend every meeting. This likely will have less chance of making it into C++17, although individual proposals such as fixed point still may.

Array extension has had a checkered past and likely similarly checkered future. It is a stack array with size that is not known at compile time. It has been started, then pulled out, then at Kona, direction was given after a special discussion in EWG to that can be used as framework for future proposal. It will not be in C++17

See you after Jacksonville meeting. Thanks.