[libcxx-commits] [PATCH] D101948: [libc++] Future-proof std::copy for ranges

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

Quuxplusone added a comment.

You can guess that I dislike any approach that seems to lead to one-file-per-function. :)  What I personally would do is,
(1) Rename `<algorithm>` to `<__algorithm/base.h>`, and have `<algorithm>` simply `#include <__algorithm/base.h>`.
(2) Move all public entrypoints (`sort`, `lower_bound`, `copy`...) into `<__algorithm/classic.h>`, and have `<algorithm>` also include that. Leave all the private implementations (`__sort`, `__lower_bound`, `__copy`...) in `<__algorithm/base.h>`.
(3) Change all private implementations from `template<class _Iter>` to `template<class _Iter, class _Sent>`. (This change will be local to `<__algorithm/base.h>`.)
(4) Implement `<__algorithm/ranges.h>` as more-or-less an exact copy of `<__algorithm/classic.h>`, just using niebloids instead of plain old function templates.

The important thing IMO is to have a way for internal users to get the classic stuff without the Ranges stuff.

Btw, I observe that right now `<string_view>` includes `<algorithm>` AFAICT //only// for `std::min`. For that reason, I suggest that a "common prefix" (maybe the //longest// common prefix :P) of our two approaches would be for you to make a PR pulling out `<__algorithm/min_max.h>`, which could also serve as a testbed for some aspects of Ranges. (Eventually we'll have to create `std::ranges::min` and `std::ranges::max`, but we certainly don't want to drag all of Ranges into `<string_view>`...)

`std::copy` is also an "interesting" first testbed, because it's all tangled up with `__wrap_iter` and `__is_cpp17_contiguous_iterator`, which are still quite actively mutating at the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101948