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

JF Bastien via libcxx-dev libcxx-dev at lists.llvm.org
Fri May 17 09:44:43 PDT 2019



> On May 17, 2019, at 8:18 AM, Marshall Clow via libcxx-dev <libcxx-dev at lists.llvm.org> 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:
> 
> A large problem for the C++ commitee and standardization in general is that we don't actually get feedback from
> the experimental components we standardize and which standard libraries ship.
> 
> We want user feedback. And user feedback only comes when vendors can ship these experiments to users.
> 
> Right.
>  
> 
> The utility of feedback is it allows us to fix the experimental specification before it becomes locked in. This means
> allowing experimental implementation to change and evolve. We need to be allowed to make breaking changes.
> This requires breaking users.
> 
> Agreed.
>  
> 
> With that in mind, here are my thoughts on the proposal:
> 
> * The "experimental" treatment should apply only to components the ISO C++ committee deems "experimental".
> 
> * `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.
> 
> Right.
>  
> * We want to make it easy for users to transition from `std::experimental::foo` to `std::foo`.
> 
> I don't see how we (libc++) have any affect on this; other than making sure that `std::foo` is available.
> 
> * It's super surprising when  `std::experimental::foo` and  `std::foo` both exist but have different behavior. If 
>   the `std::` version changed, we should consider this a bug fix against the experimental specification. Having
>   two disparate sets of behavior helps no one.
> 
> I disagree here; each one has a different specification.
> We should match the specs. If someone wants the new behavior in std::foo, then they should use std::foo.
> 
> In the long (or even not-so-long) run, there should be only one: `std::foo`. 
> Once that has landed in a shipping standard, we should get rid of `std::experimental::foo` as soon as possible.

I think that Eric is saying is: people use std::experimental::optional because they want optional, whatever that is. They don’t really understand what “experimental" means. When they try to migrate to the standard version, it *is* surprising that stuff changes, or that they have to upgrade to C++17.

I agree that they’re using “experimental” wrong if that’s their expectation… but it is their expectation nonetheless! And it now looks like we’ve pushed churn onto them. What Louis is trying to do is make “experimental”’s meaning more obvious, while also giving users more runway for deprecation (so they can upgrade at their leisure). It’ll make it less frustrating for people who use experimental stuff. That’s desirable because we want their feedback! If we burn them with experiments they won’t want to try out our experiments, and we’ll be poorer for it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190517/73122e1b/attachment.html>


More information about the libcxx-dev mailing list