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

[Marshall Clow via libcxx-dev]

On Mon, May 20, 2019 at 10:34 AM Louis Dionne <ldionne at apple.com> wrote:

>
>
> On May 17, 2019, at 13:16, Marshall Clow <mclow.lists at gmail.com> wrote:
>
> On Thu, May 16, 2019 at 11:18 PM Eric Fiselier <eric at efcs.ca> wrote:
>
>> I'm coming into this conversation late, so let me pontificate for a
>> moment:
>>
> [snip]
>
>>
>> With that in mind, here are my thoughts on the proposal:
>>
>> * `std::experimental::foo` and `std::foo` are different things. It's
>> important for users to understand that
>>   `std::experimental::foo` provides none of  the same API/ABI stability
>> guarantees `std::foo` does.
>>
>>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>
>>
> Not only that, but there is no guarantee that  `std::experimental::foo`
> and `std::foo` behave the same.
> (Similar, almost certainly yes - but in detail, probably not)
> Optional is the poster child here.
>
> If people want stability, guarantees against breaking changes, etc. - then
> they should not use stuff in std::experimental.
> Period. Full stop.
> Wait for it to appear in a standard.
>
>
> Okay, so I had a discussion with Marshall last Friday, and I'd like to
> summarize the current situation and where we disagree. Marshall, please
> feel free to amend anything I say below.
>

Thanks for summarizing.
Will do :-)


> My main gripe is that the user experience for experimental features is
> currently not excellent.
>

Agreed.


> In particular, users are making assumptions they shouldn't make about
> experimental features, and they end up using those features in places where
> an experimental feature wouldn't belong (e.g. an API boundary of a stable
> library, or somewhere that requires ABI stability). This ends up biting
> them (and hence us too) when we break those assumptions. Note that I fully
> understand this is a "users are misbehaving" kind of problem. However, I
> think it is unrealistic to expect users to know about TSes, Standard
> release cycles, and even important things like ABI stability. I think we
> must put mechanisms in place to force them to behave correctly.
>

I disagree here. These are professional software developers; who are making
their livelihood producing software.
Expecting them to be informed is not unreasonable.

More specifically, I'm trying to address the problem on three main fronts:
> 1. I want users to opt-in explicitly and at the compiler flag level to get
> experimental features. Otherwise, the declarations are not present in the
> headers. This way, by default, they don't have access to experimental
> features. If they want them, they must enable the flag in their project
> (and all dependent projects in case of a library), which I claim is going
> to make them understand the experimental nature of those features.
>

I believe that referencing the `experimental` namespace is just as
significant an opt-in.


> 2. I want to have a user-friendly way of using non header-only
> experimental features. This is a nice-to-have.
>

Agreed. This would be nice.  As I've said before, I'm fine with adding
`-fexperimental` as a syonym for `-lc++experimental`.


> 3. I want to have a user-visible way of warning users that an experimental
> feature is going to be removed in a few LLVM releases. People don't read
> the documentation and they don't follow exactly when we implement the non
> experimental version of a feature.
>

I'm fine with this, but I believe (strongly) that the build system is not
the correct place for this.

To someone trying to get a release out (this week!) a warning on each build
that "this feature is going away in a year" is just noise, and gets in the
way of finding actual problems with the build.

I think that cramming stuff like this into the build system is a
manifestation of "when you have a hammer, everything looks like a nail".

Marshall's opinion is that adding barriers to use experimental features is
> just going to be frustrating and will not change the fact that users make
> incorrect assumptions about experimental features. We already put those
> features in a `experimental` namespace, and users are just going to add the
> compiler flag without really considering the implications.
>

Yes.

If you believe that adding `#include <experimental/optional>` (say) is done
w/o considering the implications, why do you believe that adding
`-fexperimental` to a make file will not be done in a similar manner?

I refer you to the seminal work "Copying and Pasting from Stack Overflow" (
https://www.goodreads.com/book/show/29437996-copying-and-pasting-from-stack-overflow)
:-)



> So we disagree on (1), specifically the part where -fexperimental would
> control whether we provide the declarations of experimental features in
> libc++.
>

Yes.


> However, we both agree on (2) and (3), although we don't agree on how to
> solve (3) exactly -- but I don't think that's the main point of contention.
> I see a couple of paths we can take going forward:
>
> 1. Status quo, which leads to embarrassing situations where we break users
> and tell them "it's your problem, the feature was experimental".
> 2. We adopt my proposal as-is.
> 3. We adopt my proposal but we don't add -fexperimental (or we add it but
> it only controls whether -lc++experimental is linked). It is an improvement
> over the status quo because we still agree to add deprecation warnings when
> we ship the non-experimental version of a feature.
>
> Any thoughts?
> Louis
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190520/1c51f34c/attachment-0001.html>