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

[James Y Knight via libcxx-dev]

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.

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.

On Thu, Jun 4, 2020 at 11:24 AM Shoaib Meenai <smeenai at fb.com> wrote:

> 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> 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
> <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/63ac35ec/attachment.html>