[libcxx-commits] [PATCH] D120141: [libc++] Granularize chrono includes

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added a comment.

In D120141#3341656 <https://reviews.llvm.org/D120141#3341656>, @EricWF wrote:

> I know this has already been litigated, but I was hoping someone could fill
> me in on what exactly we're trying to accomplish by breaking up these
> includes?

Various partial answers depending on what exactly the question is:

- By including just the bits of <chrono> we need, instead of all of <chrono>, we (handwavily, might) speed up compile times.
- By including just the bits of <chrono> we need, we make the code a little bit more self-documenting: libc++ header H uses exactly //these// components from <chrono>, no need for the reader to hunt each of them down by eyeballing H's code.
- By including just the bits of <chrono> we need, we reduce the amount of `std::` stuff transitively made available to users, which jibes with @ldionne's general "no extensions, nothing accidentally works here and breaks elsewhere" philosophy.
- By splitting up <chrono> (D116965 <https://reviews.llvm.org/D116965>), we gained some consistency, because it is (now) libc++ style that big headers get split up. Now nobody has to ask "Why is <memory> split up and <chrono> isn't?" (Nor "Why do so many libc++ headers transitively include all of <chrono>, when we don't do that with any other header?") The snowball has rolled far enough by now that consistency is the killer app for me at this point. :)
- By splitting up headers in general,  we (arguably) make them easier to read and maintain. For <chrono> I think this argument is particularly good, because C++20 makes it double or triple in size. (Ditto <algorithm>, <ranges>, <iterator>, <memory>...) The argument lacks potency when applied to already-small things like <string>, <optional>, <any>, which is kinda why nobody's bothered to split those up yet.
- By splitting up headers in general, we handwavily make it easier to deal with the circular dependencies beloved by LEWG. The previous approach was to lift dependencies //as needed// into `<__foo_base>`, and then, if all else failed, into <type_traits>. FWIW I personally liked that approach just fine, but I admit it requires a high level of institutional knowledge about why certain things are in `<__string>` not <string>, why std::swap is in <type_traits>, and so on, which (arguably) doesn't scale if you want new contributors to make themselves useful quickly. "Pull out everything super fine-grained" is arguably lazy, but it works and it's easy to explain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120141