[libcxx-dev] Proposal for handling experimental features in libc++

Zoe Carver via libcxx-dev libcxx-dev at lists.llvm.org
Wed May 22 17:58:42 PDT 2019


I am very late to this discussion, but for what it is worth, here are
my thoughts:

> One question that is still open with this proposal is the status of features that are part of an upcoming Standard, like <span>. Those features are not really "experimental" in the sense that they are in C++20, however they are experimental in the sense that we do reserve the right to change them until the Standard has shipped. I'm not sure whether those features should be considered experimental, or whether that status should apply only to TSes.

For the most part, I think users who want C++20 know that it is not
yet complete. They opt-in by passing the -std=c++2a flag and (in most
cases) know what they are getting into. I think giving them warnings
for this will do more harm than good.

> They don't see those as two completely different types. With that point of view, they expect that if they're using std::experimental::optional in C++14, then they should be able to use std::optional in C++14 too, and they're surprised when they realize they need to move to C++17.

Are experimental headers updated with standard headers (i.e., 2014,
2017, etc.)? If so, presumably, when they move to C++17, there will be
other things for them to update (or they will at least expect there is
a possibility of the need to update). So, I don't think it will be an
issue that they also need to update their experimental code.

> That being said, let me proposal an middle ground: Let's add a compiler warning.

Why add a warning for something that has a warning in its name? I
think having a compiler spit out a bunch of warnings for perfectly
valid code does more harm than good (if I understand what you are
proposing).


Speaking from experience, getting the experimental library to work out
of the box is a huge pain. If people make it to the end and are using
it, I think they will understand what they are getting themselves
into.

Zoe


More information about the libcxx-dev mailing list