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

[Zoe Carver via libcxx-dev]

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.

On Wed, May 22, 2019 at 6:11 PM Shoaib Meenai <smeenai at fb.com> wrote:
>
> (Responding to a specific part inline, although Outlook isn't the best at handling that...)
>
> On 5/22/19, 5:59 PM, "libcxx-dev on behalf of Zoe Carver via libcxx-dev" <libcxx-dev-bounces at lists.llvm.org on behalf of libcxx-dev at lists.llvm.org> wrote:
>
>     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
>     _______________________________________________
>     libcxx-dev mailing list
>     libcxx-dev at lists.llvm.org
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=1VtS7lEkblmGkzzSwGRgbkwb8kNSzVMTEBMqeMo0ctQ&s=gYSrZCpNl-nAbSf7SrZaIdRQOUfITJ6qCCBEGyM8UHM&e=
>
>