[libcxx-commits] [PATCH] D142285: [libc++] Don't include <version> everywhere

Sun Jan 22 07:04:47 PST 2023

philnik added a comment.

In D142285#4071778 <https://reviews.llvm.org/D142285#4071778>, @Mordante wrote:

> In D142285#4071762 <https://reviews.llvm.org/D142285#4071762>, @philnik wrote:
>
>> In D142285#4071753 <https://reviews.llvm.org/D142285#4071753>, @Mordante wrote:
>>
>>> Can you please explain why this is done? What are the benefits for users/libc++ itself?
>>
>> The main benefit is avoiding the portability pitfall.
>
> That's a pitfall we have with our current design, but instead we create a language version upgrade pitfall in libc++. This means users who don't care about portability may get caught in this trap. I much rather have the portability trap, than the upgrade trap. (Preferable I would have no traps, but that ship has sailed years ago.)

There is no reason to use FTMs if you use only a single standard library though. They are only useful if you want your code to be portable.

>>> I'm not convinced this is an improvement:
>>>
>>> - most (all) toplevel headers have a generated part, which to me looks like a potential source of bugs.
>>
>> What exactly would be the problem? It's not significantly different from having `#include <__config>` or `#pragma GCC system_header` everywhere.
>
> The difference is I need to type these lines. Now the header needs a magic comment to include an auto-generated part. Some headers don't have the new magic, like ratio. So when there will be an update to ratio (for example https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2734r0.pdf) the update script won't work out-of-the-box. So we need additional instructions on how to use the update script cmake target.

The scripts tells you that they are missing when they are.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142285