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

[Marshall Clow via libcxx-dev]

On Wed, May 15, 2019 at 12:38 PM Louis Dionne via libcxx-dev <
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`.


> - 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.


> - 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.


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

Woo hoo! ;-)

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190515/92d61348/attachment.html>