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

[Marshall Clow via libcxx-dev]

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

>
> On May 15, 2019, at 4:43 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
>
> 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).
>
>
> Should something like optional only have targeted 17 then? Since that’s
> what it targeted (versus base standard). I’m not sure I like one versus
> another, but I’d like to understand your positioning and reasoning.
> Basically, I have no idea what our policy should be here and would like to
> hear arguments for one direction versus another.
>

You're going to have to be more precise here.

std::experimental::optional was a LFTS 2 thing. That TS was based on C++14.
It was available in libc++ when the user specified C++14 (or later).
[N.B. std::experimental::optional has been removed from libc++ ]

std::optional is a C++17 thing. It is available in libc++ when the user
specifies C++17 (or later).


> From what I can tell, it’s useful for new experiments features to work
> with old standards: we’ll get more input from more people because it’s
> easier to use. However, that ease means it’s harder to get rid of
> experiments later! The later is what Louis is worried about: we’ve found it
> hard with our own users. At the same time, the committee doesn’t know when
> something will actually ship (i.e. LFTS doesn’t really target a particular
> standard for release, just as a base).
>
> So I have no idea what the best policy is.
>

Many of the new TS features build upon features in the base language; which
makes supporting them for older standards ... harder.
(Not all of them, of course)

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