[libcxx-commits] [PATCH] D104980: [libcxx][NFC] replaces `<utility>` includes with specific headers

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb planned changes to this revision.
cjdb added a comment.

In D104980#2862916 <https://reviews.llvm.org/D104980#2862916>, @ldionne wrote:

> In D104980#2862532 <https://reviews.llvm.org/D104980#2862532>, @EricWF wrote:
>
>> So we're splitting up the headers (which I don't love, but will hold my tongue for the most part).
>>
>> The intention is to provide better name hygene for our users. Meaning headers will export _fewer_ names than they do at present.
>> This is an intentional BREAKING change. Users will have to update their code to include the correct headers before it will compile.
>>
>> Before we do this we need to:
>>
>> 1. Announce and discuss this change, it's rational, and its benefits to *all libc++ vendors*.
>> 2. Document the list of names removed from every header. This list should be complete.
>> 3. Ensure Clang's error messages tell users _which_ headers to include. Or at least don't tell users to include the wrong (implementation) headers.
>
> It is indeed a breaking change, albeit one that is easy to remediate for users. But on a large scale, I agree it can be challenging to tackle.
>
> While there is a clear benefit in making the headers less monolithic, minimizing the includes themselves is, as someone who just wants to ship an updated libc++, primarily a pain point. I'm willing to play ball and go through the pain of fixing my direct users (even though that's a huge pain), but if another vendor finds this change too disruptive, I can also get behind that. At the end of the day, the pain is real, but the benefit has a component of "pedantic correctness" to it. It would be a lot easier to make this change if we somehow could make it gradually, but I think the only way to do that would be for users to make sure their code always builds with modules enabled and disabled.

I'm starting to form a longer-term plan, so it would be best if we held off on merging this (and its children) till after the branch point at the end of the month. I have no idea how long it will take for my ideas to get integrated into Clang (and other relevant LLVM tools, if necessary). @ldionne I think it would also be good for us to not immediately fix anyone, so that we can get deployment experience (across multiple customers) for the features I end up implementing. Then we can publish a guide explaining how users ought to migrate to libc++next.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104980