[libcxx-commits] [PATCH] D103327: [libc++] NFC: Move std::copy to its own header

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb added a comment.

In D103327#2787763 <https://reviews.llvm.org/D103327#2787763>, @Quuxplusone wrote:

>>> But the latter would force all libc++ users of std::copy to depend on large swaths of <ranges>, so the former is the lesser evil.)
>
>
>
>> Users can only obtain std::copy by including <algorithm>
>
> @cjdb, you misunderstand what I mean when I say "libc++ users of std::copy."  Today, std::copy is used by libc++ in these headers:
>
>   $ git grep -l '_VSTD::copy('
>   __bit_reference
>   __string
>   algorithm
>   bitset
>   deque
>   locale
>   random
>   regex
>   valarray
>   vector
>
> Whereas any part of `<ranges>` at all is included by only these headers:
>
>   $ git grep -l '<_*ranges' | grep -v ^__ranges
>   ranges
>   span
>   string_view
>   version
>
> (where `<span>` and `<string_view>` include only `enable_borrowed_range.h`, and `<version>` is a false positive from a comment).
> So, forcing all these libc++ users of `_VSTD::copy` to include large swaths of `<ranges>` would indeed be a tragedy.
>
> (@ldionne, you understood my comment, right? or at the very least you understand it now?)

Fair enough; I did misunderstand, and I agree //that// is worth thinking about. I don't consider it to be tragic (our fine-grained headers minimise the surface area of what's imported), but I can see why others might.
If we //really// need to split certain things, I guess that could come down to a case-by-case basis.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103327