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

[Marshall Clow via libcxx-dev]

On Wed, May 15, 2019 at 3:52 PM JF Bastien <jfbastien at apple.com> wrote:

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

I'm saying I don't want to have experimental features available on an
earlier standard than what they're targeting (absent a VERY good 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.
>
> That’s not quite right: 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.
>
>
You get the span header, yes - but not `std::span`
I'm pretty sure that you (Apple) are not interested in shipping six
different sets of headers - one each for 98/03/11/14/17/2a

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