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

[Shoaib Meenai via libcxx-dev]

(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=