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

[Eric Fiselier via libcxx-dev]

On Wed, Jun 3, 2020 at 8:11 PM James Y Knight via libcxx-dev <
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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200604/97ca491d/attachment.html>