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
(Responding to a specific part inline, although Outlook isn't the best at handling that...)
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.
The problem here isn't that you need to update things when you're moving to C++17. The issue is that people (including several large codebases I work with) were using -std=c++14 and std::experimental::optional, and then libc++ got updated and suddenly std::experimental::optional didn't exist anymore. The ultimate goal for those codebases is to move to -std=c++17, but that's fairly involved. Moving from std::experimental::optional to std::optional as part of a move to -std=c++17 isn't really an issue, but having your existing code using std::experimental::optional break and not being in a position to easily upgrade to -std=c++17 to get std::optional is unfortunate.
> 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
Yes, that would be unfortunate. I thought experimental headers were
updated at intervals to match standard headers, my bad. Anyway, in
that case, I entirely support Louis' proposal to keep these around for
a while.