<div dir="ltr"><div dir="ltr">On Wed, Jun 3, 2020 at 8:11 PM James Y Knight via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><div><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"><div dir="ltr">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.<div><br></div><div>However, one issue is that a <i>lot</i> of code is broken by libc++'s removal of auto_ptr, random_shuffle, bind1st/bind2nd<span style="color:rgb(0,0,0)">, 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.)</div><div><br></div><div>Given:</div><div>1. There is a large amount of existing usage of these functions/classes.</div><div>2. GCC has not, and has no plans to, remove them from libstdc++.</div></div></blockquote><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>3. We ought to continue incrementing the default C++ language version in clang.</div><div>4. It would be good not to break vast swaths of existing code while doing so. </div></div></blockquote><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><br></div><div>I propose that we modify the libc++ configuration to define _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES unless __STRICT_ANSI__ is defined.</div></div></blockquote><div><br></div>I agree that libc++ should act pragmatically and allow users to upgrade without the additional cost of fixing usages of removed features.<div>I have some concerns with using `__STRICT_ANSI__`</div><div><br></div><div><div>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</div><div>configurations, nor do I want something as cryptic as the difference between `gnu++XX` and `c++XX` to cause behavioral changes in libc++.</div></div><div>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.   </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> </div><div><br></div><div>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.</div><div><br></div><div>I think that would strike a reasonable balance between not unnecessarily breaking code, and moving things forward.</div></div></blockquote><div><br></div><div>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.</div><div>So what cost do we bear for exposing them differently?</div><div><br></div><div>Are there other suggestions for how to best gate these features?</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"><div dir="ltr"><div><br></div><div>Thoughts?</div><div></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></div></div>