[libcxx-commits] [PATCH] D148432: [libc++] Simplify the tuple constructor overload set

[Nikolas Klauser via Phabricator via libcxx-commits]

philnik added a comment.

In D148432#4653206 <https://reviews.llvm.org/D148432#4653206>, @jrtc27 wrote:

> In D148432#4653195 <https://reviews.llvm.org/D148432#4653195>, @philnik wrote:
>
>> In D148432#4653189 <https://reviews.llvm.org/D148432#4653189>, @jrtc27 wrote:
>>
>>> In D148432#4653188 <https://reviews.llvm.org/D148432#4653188>, @philnik wrote:
>>>
>>>> In D148432#4653185 <https://reviews.llvm.org/D148432#4653185>, @jrtc27 wrote:
>>>>
>>>>> To clarify: what versions of GCC and Clang are required to compile this code? Whilst we can assume GCC and Clang, if this is in code paths used for old language versions, we need to be sure compilers that are supported today for those language versions continue to be able to #include this header without issue (unlike files used solely during the build of libc++ itself, where we can more aggressively require newer compilers).
>>>>
>>>> libc++ currently requires at least Clang 16 or GCC 13, so we should be good on that front. We will probably add extra coverage to the CI once we enable extensions more generally.
>>>
>>> To build, or for anyone wishing to compile code that uses it as the standard library implementation? I would be very surprised if it's the latter. What about distributions that need to compile code with older compilers?
>>
>> For anyone that wants to use it. IDK about distributions that need to use old compilers, but how often do you install a custom standard library without also installing a custom compiler? Probably just about never.
>
> libc++ isn't always a custom standard library. It's the system standard library for FreeBSD (and Android, but there's probably less concern about weird old compiler versions there). Every 6 months a new libc++ comes out, so around every 6 months (always between a bit and a lot behind) FreeBSD updates to a new version of libc++, but the freebsd-ports collection is *huge* and has many old compiler versions, both GCC and Clang, available and used. We try to avoid them where possible, but sometimes it's what has to happen. GCC in particular; code that compiles with Clang tends to be more modern and less picky about compilers.

I am aware that it's not always a custom library. May point is that it's always a custom library if you don't have a corresponding compiler, since distributions don't only ship a new libc++, at least AFAIK. This also doesn't seem to be much of a problem in reality, since we already assume these compilers in code. Anyways, I don't think our compiler support policy is relevant to whether this should land. If the support policy should change, that is a separate conversation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148432/new/

https://reviews.llvm.org/D148432