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

Fri May 24 14:26:31 PDT 2019

Okay, so I finally put together something that I think will get everyone's support. Basically, what I'm proposing for now is just that we systematically provide deprecation warnings before we remove a feature, and we remove headers when they're empty (instead of the weird trap we have right now).

There's nothing else, it's that simple! I created a Phab review implementing those changes -- please comment on the review: https://reviews.llvm.org/D62428

Thanks,
Louis

> On May 20, 2019, at 20:36, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
> 
> 
> On Mon, May 20, 2019 at 10:34 AM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote:
> 
> 
>> On May 17, 2019, at 13:16, Marshall Clow <mclow.lists at gmail.com <mailto:mclow.lists at gmail.com>> wrote:
>> 
>> On Thu, May 16, 2019 at 11:18 PM Eric Fiselier <eric at efcs.ca <mailto: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 <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/20190524/d5f8537b/attachment.html>