<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 17, 2019, at 8:18 AM, Marshall Clow via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2019 at 11:18 PM Eric Fiselier <<a href="mailto:eric@efcs.ca" class="">eric@efcs.ca</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">I'm coming into this conversation late, so let me pontificate for a moment:<div class=""><br class=""></div><div class="">A large problem for the C++ commitee and standardization in general is that we don't actually get feedback from</div><div class="">the experimental components we standardize and which standard libraries ship.</div><div class=""><br class=""></div><div class="">We want user feedback. And user feedback only comes when vendors can ship these experiments to users.</div></div></blockquote><div class=""><br class=""></div><div class="">Right.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">The utility of feedback is it allows us to fix the experimental specification before it becomes locked in. This means</div><div class="">allowing experimental implementation to change and evolve. We need to be allowed to make breaking changes.</div><div class="">This requires breaking users.</div></div></blockquote><div class=""><br class=""></div><div class="">Agreed.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">With that in mind, here are my thoughts on the proposal:</div><div class=""><br class=""></div><div class="">* The "experimental" treatment should apply only to components the ISO C++ committee deems "experimental".</div><div class=""><br class=""></div><div class="">* `std::experimental::foo` and `std::foo` are different things. It's important for users to understand that</div><div class=""> `std::experimental::foo` provides none of the same API/ABI stability guarantees `std::foo` does.</div></div></blockquote><div class=""><br class=""></div><div class="">Right.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">* We want to make it easy for users to transition from `std::experimental::foo` to `std::foo`.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don't see how we (libc++) have any affect on this; other than making sure that `std::foo` is available.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""></div><div class="">* It's super surprising when `std::experimental::foo` and `std::foo` both exist but have different behavior. If <br class=""></div><div class=""> the `std::` version changed, we should consider this a bug fix against the experimental specification. Having</div><div class=""> two disparate sets of behavior helps no one.</div></div></blockquote><div class=""><br class=""></div><div class="">I disagree here; each one has a different specification.</div><div class="">We should match the specs. If someone wants the new behavior in std::foo, then they should use std::foo.</div><div class=""><br class=""></div><div class="">In the long (or even not-so-long) run, there should be only one: `std::foo`. </div><div class="">Once that has landed in a shipping standard, we should get rid of `std::experimental::foo` as soon as possible.</div></div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""></body></html>