3

Looking through the algorithm library, there are a few std::ranges::XXX_n function have basically the same definition as their std::XXX_n counterparts, namely copy_n, fill_n, and generate_n.

The only difference between them are the ranges version often applied more concept and requires to the parameters, which probably should be added to the non-range version anyways(I mean it doesn't make sense to call a generator that is not invokable, or copy something that is not copyable); Plus you can't apply execution policy on them because they meant to be ranges.

So my guess is just to have a unifying way of calling things, or am I totally missing something?

Ranoiaetep
  • 5,872
  • 1
  • 14
  • 39
  • I presume the ranges versions are meant to be used in the ranges idiomatic fashion. Other than that, they're probably more-or-less thunks to the algorithm counterparts. – Eljay Jun 11 '21 at 21:18
  • @Eljay I thought so, but `ranges::XXX_n`s requires a starting iterator, so neither `R | XXX_n(...)` nor `XXX_n(R, ...)`would work. – Ranoiaetep Jun 11 '21 at 21:22
  • 1
    I think the idea for a lot of the constrained algorithms is that while most of the concepts and requirements used just reflect prerequisites the C++17 and earlier versions were already expecting, they're not _exactly_ the same and some existing code would be invalidated if `std::copy_n` got updated instead of superseded by `std::ranges::copy_n`. – Nathan Pierson Jun 11 '21 at 21:33

0 Answers0