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

[Marshall Clow via libcxx-dev]

On Thu, May 16, 2019 at 10:49 AM Louis Dionne <ldionne at apple.com> wrote:

>
>
> On May 16, 2019, at 12:11, Marshall Clow <mclow.lists at gmail.com> wrote:
>
>
>
> 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).
>
>
> Okay, so essentially what you're saying is that experimental features
> should always be available starting with the standard they're based on, not
> a potential standard they might end up shipping in (when taken out of the
> TS)? That clearly makes sense and it's a valid point of view.
>

Yes.


> Another point of view is that of users that don't really know anything
> about TSes and when things land in a Standard. From their perspective,
> std::experimental::optional is the same thing as std::optional, just not
> "experimental".
>

We're not in control of their ignorance.

They're not the same, and they're never going to be the same.
(Even if we didn't remove std::experimental::optional, they still would not
be the same)


> They don't see those as two completely different types. With that point of
> view, they expect that if they're using std::experimental::optional in
> C++14, then they should be able to use std::optional in C++14 too, and
> they're surprised when they realize they need to move to C++17.
>

Then they will be surprised.
They will have to learn what the difference between std::optional and
std::experimental::optional is (along with the differences between the two)


> I understand both points of view, however I think the second one serves
> our users best because, like I said, they don't know about TSes and they
> don't (nor should they) understand the standardization process.
>

Then they should avoid everything in std::experimental.
There's a reason it was named that. Things there are EXPERIMENTAL. As in,
NOT STANDARD.



> That being said, I'd be fine with adopting the first point of view (i.e.
> that std::experimental::optional should be available starting with C++14
> but std::optional only with C++17), at least for now. At least, if users
> are required to opt-in explicitly, I think this makes everything much
> easier.
>
> Louis
>
>
>
>> 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/bf6df7ac/attachment.html>