<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="">First, I agree with Eric about not adding yet another dimension of configuration to libc++. I know for you it might appear like just a convenience, however the number of configurations supported by libc++ is already too large to maintain, so the only thing we should do is reduce it, not increase it.<div class=""><br class=""></div><div class="">On a different level, I believe that libc++ should implement the Standard, and the Standard has decided to remove these features from C++17. Hence, I believe it is entirely reasonable for libc++ not to provide these features in C++17, and in fact I view the fact that we allow un-removing them merely as a gentle approach to help people upgrade. In the future, I believe that we should unconditionally remove these features from C++17.</div><div class=""><br class=""></div><div class="">I think it's a great idea to update the standard mode for Clang to C++17 (or Gnu++17), however I don't think libc++ should bend itself in order to make arbitrary code bases compile out-of-the-box when they don't conform to the Standard mode they are trying to use. It seems to me like either:</div><div class="">(1) these code bases are not maintained anymore and there's no intent to update them, so it's better for them to just acknowledge that and compile them as C++14, or</div><div class="">(2) these code bases are maintained, and we're trying to use these removed features to save the work of actually updating the code base.</div><div class=""><br class=""></div><div class="">In both cases, I think that providing these removed features in C++17 is just playing ostrich with the real issue.</div><div class=""><br class=""></div><div class="">Louis</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2020, at 15:37, James Y Knight 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 class=""><div class=""></div></div><div class="">Exposing some extensions beyond the standard is the intent behind there being a separate -std=gnu++17 flag, vs -std=c++17, so that doesn't really feel like a cryptic behavioral change to me for libc++ to expose the no-longer-standard functions only in -std=gnu++17.</div><div class=""><br class=""></div><div class="">But it'd also be fine by me to just keep them enabled by default in all modes -- the important part is that they get enabled in the default compilation mode. Regarding opt-out -- we could perhaps honor the flag being set explicitly to zero, e.g. -D_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES=0.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 11:24 AM Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank" class="">smeenai@fb.com</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 lang="EN-US" class="">
<div class=""><p class="MsoNormal">Although I understand and support the rationale here, I’d still like some way to opt out of libc++ exposing these removed features. For us, the C++17 upgrade was an excellent opportunity to find and modernize all these issues in our codebase.
(I know that ideally you should be doing that on a more regular basis, and that e.g. there’s clang-tidy tools to help with that, but the upgrade was a nice forcing function.)<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in" class=""><p class="MsoNormal" style="margin-left:0.5in"><b class=""><span style="font-size: 12pt;" class="">From:
</span></b><span style="font-size: 12pt;" class="">libcxx-dev <<a href="mailto:libcxx-dev-bounces@lists.llvm.org" target="_blank" class="">libcxx-dev-bounces@lists.llvm.org</a>> on behalf of Eric Fiselier via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" class="">libcxx-dev@lists.llvm.org</a>><br class="">
<b class="">Reply-To: </b>Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank" class="">eric@efcs.ca</a>><br class="">
<b class="">Date: </b>Thursday, June 4, 2020 at 1:09 AM<br class="">
<b class="">To: </b>James Y Knight <<a href="mailto:jyknight@google.com" target="_blank" class="">jyknight@google.com</a>><br class="">
<b class="">Cc: </b>Libc++ Dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" class="">libcxx-dev@lists.llvm.org</a>><br class="">
<b class="">Subject: </b>Re: [libcxx-dev] Enable _LIBCPP_ENABLE_*_REMOVED_* by default in -std=gnu++NN?<u class=""></u><u class=""></u></span></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in">On Wed, Jun 3, 2020 at 8:11 PM James Y Knight via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" class="">libcxx-dev@lists.llvm.org</a>> wrote:<u class=""></u><u class=""></u></p>
</div>
<div class="">
<div class="">
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in">It seems to me like it may be reasonable to increment the default language version in Clang from -std=gnu++14 to -std=gnu++17 soon.<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">However, one issue is that a <i class="">lot</i> of code is broken by libc++'s removal of auto_ptr, random_shuffle, bind1st/bind2nd<span style="" class="">, ptr_fun/mem_fun/</span>mem_fun_ref/etc. (And almost nothing is
broken by the removal of {set_,get_,}unexpected, but I'm not sure it makes sense to actually treat that differently.)<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">Given:<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">1. There is a large amount of existing usage of these functions/classes.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">2. GCC has not, and has no plans to, remove them from libstdc++.<u class=""></u><u class=""></u></p>
</div>
</div>
</blockquote>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in">3. We ought to continue incrementing the default C++ language version in clang.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">4. It would be good not to break vast swaths of existing code while doing so. <u class=""></u><u class=""></u></p>
</div>
</div>
</blockquote>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">I propose that we modify the libc++ configuration to define _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES unless __STRICT_ANSI__ is defined.<u class=""></u><u class=""></u></p>
</div>
</div>
</blockquote>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div><p class="MsoNormal" style="margin-left:0.5in">I agree that libc++ should act pragmatically and allow users to upgrade without the additional cost of fixing usages of removed features.<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">I have some concerns with using `__STRICT_ANSI__`<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in">Currently, there is no distinction in libc++ between `-std=c++XX` and `-std=gnu++xx`; I don't want to double the number of supported<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">configurations, nor do I want something as cryptic as the difference between `gnu++XX` and `c++XX` to cause behavioral changes in libc++.<u class=""></u><u class=""></u></p>
</div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">In the past libc++ has been bitten by similar behavior changes when `-pedantic` is specified. This feels like it will cause the same sorts of problems. <u class=""></u><u class=""></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in"> <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">That define is set only if the user explicitly passes --std=c++XX. In the default compilation mode, the removed functionality would continue to be available, and only users who ask for a strict compliance mode would
get an error.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">I think that would strike a reasonable balance between not unnecessarily breaking code, and moving things forward.<u class=""></u><u class=""></u></p>
</div>
</div>
</blockquote>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">For libc++ and it's maintainers, there is no balance to be struck here, and there never will be. I believe the library has already committed to supporting the removed features ad infinitum.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">So what cost do we bear for exposing them differently?<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">Are there other suggestions for how to best gate these features?<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-left:0.5in"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-left:0.5in">Thoughts?<u class=""></u><u class=""></u></p>
</div>
</div><p class="MsoNormal" style="margin-left:0.5in">_______________________________________________<br class="">
libcxx-dev mailing list<br class="">
<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" class="">libcxx-dev@lists.llvm.org</a><br class="">
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=zPV9YBKxKhCu6NrzimnD5WmZWYSGDza0lp95TVLl3cc&s=B7SwIBbwleY9v-ag8Um6SA_lFA888xNMp4AzMru8u7Y&e=" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><u class=""></u><u class=""></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote></div>
_______________________________________________<br class="">libcxx-dev mailing list<br class=""><a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<br class=""></div></blockquote></div><br class=""></div></body></html>