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

Wed May 15 15:52:44 PDT 2019

> On May 15, 2019, at 2:24 PM, Marshall Clow via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Wed, May 15, 2019 at 12:38 PM Louis Dionne via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> Hi,
> 
> The way libc++ currently handles experimental features makes it difficult for vendors to ship those experimental features to their users with a good user experience. The main problems are:
> 
> - Experimental features are currently not opt-in, yet we remove them when they get standardized
> - The standard in which an experimental feature is promoted to non-experimental usually doesn't match the standard the experimental feature was provided in, which creates a trap for users. For example, we removed <experimental/optional> (which was available in C++14) in favour of <optional> (available in C++17 only). Users that were using <experimental/optional> now need to BOTH upgrade to C++17, and start using <optional>.
> - We currently still provide <experimental/*> headers after they've been removed, which is not super friendly for __has_include.
> 
> I'd like to request comments on the following plan for supporting experimental features going forward:
> 
> - We add a `-fexperimental` flag to Clang that libc++ can pick up. Experimental features are only enabled when that flag is passed. Note that we could also have Clang automatically link in `-lc++experimental` when `-fexperimental` is used.
> 
> The only problem that I see here is that people who are using experimental features will have to modify their build systems to pass `-fexperimental`.

That seems acceptable, no? It makes it easier when those experimental features have a runtime (in which case you’ve already passed an extra argument).

> - Experimental features are free to be available starting with whatever version of the Standard we want, since users are opting-in explicitly anyway.
> 
> In general, I think that this is a bad idea; because the TSes are always based on some existing standard.
> For example, the LFTS 2 was based on C++14, and LFTS 3 is based on C++17.
> I don't think we should mess with that w/o a compelling reason.

Are you saying that you’d rather have the experimental feature available on exactly the standard version it’s based on, and not the standard version it potentially targets?

> - When we standardize an experimental feature, we keep the experimental feature around but we add a warning saying it will be removed in 2 LLVM releases.
> - After 2 LLVM releases, we REMOVE the feature, meaning we remove the code associated to it (and the header too if there's nothing else in the header). We do not leave the header there with a warning or an error, as this is just confusing.
> 
> I think this is fairly simple and it should address all the problems I listed by simply forcing users to be explicit about what they want. I like adding a flag to Clang since it can handle linking in static libraries as needed, which is not currently possible.
> 
> 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.
> 
> We have a flag for those already. it's named `-std`. The only way you get <span> is to pass `-std=c++2a`. I don't think we need another flag.

That’s not quite right: https://godbolt.org/z/D2c_r1 <https://godbolt.org/z/D2c_r1>
I can get <span> in C++17… It’s just empty! That ain’t great either, but I don’t think Louis is proposing to fix it at this point in time.

> I'm signing up to do all the work entailed by this proposal.
> 
> Woo hoo! ;-)
> 
> -- Marshall
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190515/96f7d8bd/attachment-0001.html>