[libcxx-commits] [PATCH] D148432: [libc++] Simplify the tuple constructor overload set
Aaron Ballman via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Mon May 15 04:45:26 PDT 2023
aaron.ballman added a comment.
In D148432#4340367 <https://reviews.llvm.org/D148432#4340367>, @philnik wrote:
> In D148432#4339935 <https://reviews.llvm.org/D148432#4339935>, @Mordante wrote:
>
>> If we want to go in this direction we should document which extensions are allowed and which are not.
>> Preferably after making sure what the policy of these undocumented compiler features for different vendors
>> mean. Note that libc++ has removed backported features when they resulted in a maintenance burden.
>> I don't expect that be as troublesome in compilers, but I'm not sure.
>
> If I understand @aaron.ballman's comments correctly, they consider all documented extensions to be very hard to impossible to remove, and AFAICT quite easy to keep support for (at least for the from-later-standards ones). If you want, we can reach out to GCC folks to make sure they don't see things drastically different (which I don't expect given the amount of, even non-conforming, GNU extensions).
Correct -- we'll remove an extension if there's significant evidence that it isn't being used in the wild and it is causing serious problems (security, maintenance, is fundamentally broken, etc). However, if the extension is being used by libc++, then it's definitely getting used in the wild and unless there's literally no other option but to tear it out, we'll basically have to find a way to make it work. Generally speaking though, documented extensions don't get removed.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148432/new/
https://reviews.llvm.org/D148432
More information about the libcxx-commits
mailing list