CppCon 2016: "C++ Standard Library Panel"
101 3 11039
Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/cppcon/cppcon2016
Want to meet your standard library maintainer? Now's your chance! Join us for a panel discussion of the C++ standard library with the people who implement it! C++ standard library maintainers and members of the C++ Committee's Library Working Group will talk about the philosophy behind the specification and implementation of the C++ standard library. We'll talk about all the new library features coming in C++17 (and beyond).
Videos Filmed & Edited by Bash Films: http://www.BashFilms.com
By anonymous 2017-09-20
Someone from the audience asked a question during the "C++ Standard Library Panel" talk at CppCon 2016 (YouTube) about the potential for the name
experimental to scare users away from using anything within the namespace:
Do you guys consider [the contents of the
std::experimentalnamespace] production ready and is that an argument that can be made, [that] it's effectively production ready for the next 3 years, and maybe you have to change your code 3 years later, maybe?
Michael Wong (chair of SG5 and SG14 and editor of the Concurrency TS) fielded the question first:
I think there's strong consensus within the committee that it is practically production ready. As I said before, in most cases 99% of it gets air-dropped in. We want to make sure that it's not an impediment for you to use it. You can understand why we want to put big features, large groups of features, in such a context, so that it doesn't disturb the rest of the whole library system, but it also makes it easier for you to use it. Now you can turn on GCC with a specific flag for Concepts, you know, that actually makes it easier for you to segment it out.
Alisdair Meredith (former chair of the LWG) then followed up:
I'm going to take the contrary position here. One of the things Herb [Sutter] said as convener of WG21, the standard group, when we set off down the path of TSes is, he didn't think that TSes will have succeeded until we have failed to bring something forward, because it means we're not being experimental enough, we're not being ambitious enough in what we're using the TSes for. We really do want that
experimentalto be a hint that, yes, these things are subject to change, we're not binding to that, and we can get things wrong. This is to lower our barrier for the things we consider to be as ambitious and reach as we can [...] Now the standard seems to be on a three-year release cycle, we should be much more ambitious in putting really experimental features into the TS, and perhaps advancing things more rapidly into the main standard itself. But again, this will be a fun topic for us to discuss at the next few [C++ standard committee] meetings.
Stephan T. Lavavej (maintainer of Microsoft's STL implementation) was last to respond:
It's important to draw a distinction between the experimentalness of interface and the experimentalness of the implementation, because when you say "production ready", what does that mean? Usually, "production ready", you would think of that talking about the implementation. It's quite possible for an implementation [of something in
std::experimental] to be absolutely [...] bulletproof. [...] Something like [...] the
<random>header in TR1, [it was] really, really nice in TR1, and you could have had an absolutely bullet-proof implementation of that, but it turned out that the interface churned substantially [before the release of] C++11 and [...] if we knew back then what we do now, putting in an
experimentalwould have been a better signal to people that, "Hey, maybe you don't want to use
std::experimental::variate_generatorbecause, ha-ha, it's going to disappear in C++11".
So it seems that there is some desire among the standard library developers and committee members that, in the future at least, the contents of the
std::experimental namespace should be truly "experimental" in nature, and it should not be taken for granted that something in
std::experimental will make it into the C++ standard.
And no, as far as I understand, it is up to standard library vendors as to whether they provide implementations for the various features within