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

[Louis Dionne via libcxx-dev]

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.
- Experimental features are free to be available starting with whatever version of the Standard we want, since users are opting-in explicitly anyway.
- 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.

I'm signing up to do all the work entailed by this proposal.

Comments?
Louis