<div dir="ltr">I'm coming into this conversation late, so let me pontificate for a moment:<div><br></div><div>A large problem for the C++ commitee and standardization in general is that we don't actually get feedback from</div><div>the experimental components we standardize and which standard libraries ship.</div><div><br></div><div>We want user feedback. And user feedback only comes when vendors can ship these experiments to users.</div><div><br></div><div>The utility of feedback is it allows us to fix the experimental specification before it becomes locked in. This means</div><div>allowing experimental implementation to change and evolve. We need to be allowed to make breaking changes.</div><div>This requires breaking users.</div><div><br></div><div>With that in mind, here are my thoughts on the proposal:</div><div><br></div><div>* The "experimental" treatment should apply only to components the ISO C++ committee deams "experimental".</div><div><br></div><div>* `std::experimental::foo` and `std::foo` are different things. It's important for users to understand that</div><div>  `std::experimental::foo` provides none of  the same API/ABI stability guarantees `std::foo` does.</div><div><br></div><div>* We want to make it easy for users to transition from `std::experimental::foo` to `std::foo`.</div><div><br></div><div>* It's super surprising when  `std::experimental::foo` and  `std::foo` both exist but have different behavior. If </div><div>  the `std::` version changed, we should consider this a bug fix against the experimental specification. Having</div><div>  two disparate sets of behavior helps no one.</div><div><br></div><div>libc++ should be hyper-sensitive to the needs of vendors like Apple here. Otherwise our experimental </div><div>components find no audience. </div><div><br></div><div>Thanks for working on this Louis</div><div><br></div><div>/Eric</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 17, 2019 at 12:02 AM Marshall Clow via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></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"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2019 at 10:49 AM Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On May 16, 2019, at 12:11, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:</div><br class="gmail-m_8413968160189468507gmail-m_-2729495664310183807gmail-m_-2102711123769448119Apple-interchange-newline"><div><br class="gmail-m_8413968160189468507gmail-m_-2729495664310183807gmail-m_-2102711123769448119Apple-interchange-newline"><br style="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;text-decoration:none"><div class="gmail_quote" style="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;text-decoration:none"><div dir="ltr" class="gmail_attr">On Wed, May 15, 2019 at 8:11 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:<br></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="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr">On May 15, 2019, at 4:43 PM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:<br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 15, 2019 at 3:52 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div>On May 15, 2019, at 2:24 PM, Marshall Clow via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:</div><div><div dir="ltr" style="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;text-decoration:none"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 15, 2019 at 12:38 PM Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br><br>The way libc++ currently handles experimental features makes it difficult for vendors to ship those experimental features to their users with a good user experience. The main problems are:<br><br>- Experimental features are currently not opt-in, yet we remove them when they get standardized<br>- The standard in which an experimental feature is promoted to non-experimental usually doesn't match the standard the experimental feature was provided in, which creates a trap for users. For example, we removed <experimental/optional> (which was available in C++14) in favour of <optional> (available in C++17 only). Users that were using <experimental/optional> now need to BOTH upgrade to C++17, and start using <optional>.<br>- We currently still provide <experimental/*> headers after they've been removed, which is not super friendly for __has_include.<br><br>I'd like to request comments on the following plan for supporting experimental features going forward:<br><br>- We add a `-fexperimental` flag to Clang that libc++ can pick up. Experimental features are only enabled when that flag is passed. Note that we could also have Clang automatically link in `-lc++experimental` when `-fexperimental` is used.<br></blockquote><div><br></div><div>The only problem that I see here is that people who are using experimental features will have to modify their build systems to pass `-fexperimental`.</div></div></div></div></blockquote><div><br></div><div>That seems acceptable, no? It makes it easier when those experimental features have a runtime (in which case you’ve already passed an extra argument).</div><br><blockquote type="cite"><div><div dir="ltr" style="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;text-decoration:none"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- Experimental features are free to be available starting with whatever version of the Standard we want, since users are opting-in explicitly anyway<br></blockquote><div><br></div><div>In general, I think that this is a bad idea; because the TSes are always based on some existing standard.</div><div>For example, the LFTS 2 was based on C++14, and LFTS 3 is based on C++17.</div><div>I don't think we should mess with that w/o a compelling reason.</div></div></div></div></blockquote><div><br></div><div>Are you saying that you’d rather have the experimental feature available on exactly the standard version it’s based on, and not the standard version it potentially targets?</div></div></div></blockquote><div><br></div><div>I'm saying I don't want to have experimental features available on an earlier standard than what they're targeting (absent a VERY good reason).</div></div></div></div></blockquote><div><br></div><div>Should something like optional only have targeted 17 then? Since that’s what it targeted (versus base standard). I’m not sure I like one versus another, but I’d like to understand your positioning and reasoning. Basically, I have no idea what our policy should be here and would like to hear arguments for one direction versus another. </div></div></blockquote><div><br></div><div>You're going to have to be more precise here.</div><div><br></div><div>std::experimental::optional was a LFTS 2 thing. That TS was based on C++14. It was available in libc++ when the user specified C++14 (or later).</div><div>[N.B. std::experimental::optional has been removed from libc++ ]</div><div><br></div><div>std::optional is a C++17 thing. It is available in libc++ when the user specifies C++17 (or later).</div></div></div></blockquote><div><br></div><div>Okay, so essentially what you're saying is that experimental features should always be available starting with the standard they're based on, not a potential standard they might end up shipping in (when taken out of the TS)? That clearly makes sense and it's a valid point of view.</div></div></div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Another point of view is that of users that don't really know anything about TSes and when things land in a Standard. From their perspective, std::experimental::optional is the same thing as std::optional, just not "experimental".<br></div></div></blockquote><div><br></div><div>We're not in control of their ignorance.</div><div><br></div><div>They're not the same, and they're never going to be the same.</div><div>(Even if we didn't remove std::experimental::optional, they still would not be the same)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>They don't see those as two completely different types. With that point of view, they expect that if they're using std::experimental::optional in C++14, then they should be able to use std::optional in C++14 too, and they're surprised when they realize they need to move to C++17.</div></div></div></blockquote><div><br></div><div>Then they will be surprised.</div><div>They will have to learn what the difference between std::optional and std::experimental::optional is (along with the differences between the two)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>I understand both points of view, however I think the second one serves our users best because, like I said, they don't know about TSes and they don't (nor should they) understand the standardization process. </div></div></div></blockquote><div><br></div><div>Then they should avoid everything in std::experimental. </div><div>There's a reason it was named that. Things there are EXPERIMENTAL. As in, NOT STANDARD. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>That being said, I'd be fine with adopting the first point of view (i.e. that std::experimental::optional should be available starting with C++14 but std::optional only with C++17), at least for now. At least, if users are required to opt-in explicitly, I think this makes everything much easier.<br></div><div><br></div><div>Louis</div><br><blockquote type="cite"><div><div class="gmail_quote" style="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;text-decoration:none"><div> </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="auto"><div>From what I can tell, it’s useful for new experiments features to work with old standards: we’ll get more input from more people because it’s easier to use. However, that ease means it’s harder to get rid of experiments later! The later is what Louis is worried about: we’ve found it hard with our own users. At the same time, the committee doesn’t know when something will actually ship (i.e. LFTS doesn’t really target a particular standard for release, just as a base). <br></div><div><br></div><div>So I have no idea what the best policy is.</div></div></blockquote><div> </div><div><div>Many of the new TS features build upon features in the base language; which makes supporting them for older standards ... harder.</div><div>(Not all of them, of course)</div></div><div><br></div><div>-- Marshall</div></div></div></blockquote></div><br></div></blockquote></div></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div>