<div dir="ltr"><div dir="ltr"><br></div><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">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><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> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- When we standardize an experimental feature, we keep the experimental feature around but we add a warning saying it will be removed in 2 LLVM releases.<br>
- After 2 LLVM releases, we REMOVE the feature, meaning we remove the code associated to it (and the header too if there's nothing else in the header). We do not leave the header there with a warning or an error, as this is just confusing.<br>
<br>
I think this is fairly simple and it should address all the problems I listed by simply forcing users to be explicit about what they want. I like adding a flag to Clang since it can handle linking in static libraries as needed, which is not currently possible.<br>
<br>
One question that is still open with this proposal is the status of features that are part of an upcoming Standard, like <span>. Those features are not really "experimental" in the sense that they are in C++20, however they are experimental in the sense that we do reserve the right to change them until the Standard has shipped. I'm not sure whether those features should be considered experimental, or whether that status should apply only to TSes.<br></blockquote><div><br></div><div>We have a flag for those already. it's named `-std`. The only way you get <span> is to pass `-std=c++2a`. I don't think we need another flag.</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">I'm signing up to do all the work entailed by this proposal.<br></blockquote><div><br></div><div>Woo hoo! ;-)</div><div><br></div><div>-- Marshall</div></div></div>