<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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).<div class=""><br class=""></div><div class="">There's nothing else, it's that simple! I created a Phab review implementing those changes -- please comment on the review: <a href="https://reviews.llvm.org/D62428" class="">https://reviews.llvm.org/D62428</a></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Louis<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2019, at 20:36, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" class="">mclow.lists@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 10:34 AM Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 17, 2019, at 13:16, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank" class="">mclow.lists@gmail.com</a>> wrote:</div><br class="gmail-m_2760373480084135376Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">On Thu, May 16, 2019 at 11:18 PM Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank" class="">eric@efcs.ca</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: 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></blockquote><div class="">[snip] </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: 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="">* `std::experimental::foo` and `std::foo` are different things. It's important for users to understand that</div><div class=""> <span class="Apple-converted-space"> </span>`std::experimental::foo` provides none of the same API/ABI stability guarantees `std::foo` does.</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer" target="_blank" class=""></a></blockquote></div></blockquote><div class=""><br class=""></div><div class="">Not only that, but there is no guarantee that `std::experimental::foo` and `std::foo` behave the same.</div><div class="">(Similar, almost certainly yes - but in detail, probably not)</div><div class="">Optional is the poster child here.</div><div class=""><br class=""></div><div class="">If people want stability, guarantees against breaking changes, etc. - then they should not use stuff in std::experimental. </div><div class="">Period. Full stop.</div><div class="">Wait for it to appear in a standard.</div></div></div></div></blockquote><br class=""></div><div class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for summarizing. </div><div class="">Will do :-)</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">My main gripe is that the user experience for experimental features is currently not excellent.<span class="Apple-converted-space"> </span></div></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-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I disagree here. These are professional software developers; who are making their livelihood producing software.</div><div class="">Expecting them to be informed is not unreasonable.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">More specifically, I'm trying to address the problem on three main fronts:<br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">I believe that referencing the `experimental` namespace is just as significant an opt-in. </div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">2. I want to have a user-friendly way of using non header-only experimental features. This is a nice-to-have.</div></div></blockquote><div class=""><br class=""></div><div class="">Agreed. This would be nice. As I've said before, I'm fine with adding `-fexperimental` as a syonym for `-lc++experimental`.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm fine with this, but I believe (strongly) that the build system is not the correct place for this.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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".</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Yes. </div><div class=""><br class=""></div><div class="">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? </div><div class=""><br class=""></div><div class="">I refer you to the seminal work "Copying and Pasting from Stack Overflow" (<a href="https://www.goodreads.com/book/show/29437996-copying-and-pasting-from-stack-overflow" class="">https://www.goodreads.com/book/show/29437996-copying-and-pasting-from-stack-overflow</a>) :-)</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""></div><div class="">So we disagree on (1), specifically the part where -fexperimental would control whether we provide the declarations of experimental features in libc++.</div></div></blockquote><div class=""><br class=""></div><div class="">Yes.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">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:<br class=""></div><div class=""><br class=""></div><div class="">1. Status quo, which leads to embarrassing situations where we break users and tell them "it's your problem, the feature was experimental".</div><div class="">2. We adopt my proposal as-is.</div><div class="">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.</div><div class=""><br class=""></div><div class="">Any thoughts?</div><div class="">Louis</div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>