[libcxx-dev] Enable _LIBCPP_ENABLE_*_REMOVED_* by default in -std=gnu++NN?

[Shoaib Meenai via libcxx-dev]

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.)

From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org> on behalf of Eric Fiselier via libcxx-dev <libcxx-dev at lists.llvm.org>
Reply-To: Eric Fiselier <eric at efcs.ca>
Date: Thursday, June 4, 2020 at 1:09 AM
To: James Y Knight <jyknight at google.com>
Cc: Libc++ Dev <libcxx-dev at lists.llvm.org>
Subject: Re: [libcxx-dev] Enable _LIBCPP_ENABLE_*_REMOVED_* by default in -std=gnu++NN?

On Wed, Jun 3, 2020 at 8:11 PM James Y Knight via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:
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.

However, one issue is that a lot of code is broken by libc++'s removal of auto_ptr, random_shuffle, bind1st/bind2nd, ptr_fun/mem_fun/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.)

Given:
1. There is a large amount of existing usage of these functions/classes.
2. GCC has not, and has no plans to, remove them from libstdc++.
3. We ought to continue incrementing the default C++ language version in clang.
4. It would be good not to break vast swaths of existing code while doing so.

I propose that we modify the libc++ configuration to define _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES unless __STRICT_ANSI__ is defined.

I agree that libc++ should act pragmatically and allow users to upgrade without the additional cost of fixing usages of removed features.
I have some concerns with using `__STRICT_ANSI__`

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
configurations, nor do I want something as cryptic as the difference between `gnu++XX` and `c++XX` to cause behavioral changes in libc++.
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.


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.

I think that would strike a reasonable balance between not unnecessarily breaking code, and moving things forward.

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.
So what cost do we bear for exposing them differently?

Are there other suggestions for how to best gate these features?


Thoughts?
_______________________________________________
libcxx-dev mailing list
libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200604/96aa5da3/attachment-0001.html>