19

Many functions in the C++ Algorithms library have overloads taking a parameter of type ExecutionPolicy, e.g. std::copy. However, I noticed that the corresponding functions in the std::ranges namespace do not have these parallel overloads. This is unfortunate because it means that for many cases the non-ranged variants will be more useful.

What is the reason for this? And are there proposals to add parallel overloads to the std::ranges namespace?

SWdV
  • 1,715
  • 1
  • 15
  • 36
  • probably they ran out of time, I remember Niebler saying that ranges is huge already and that not everything in range-v3 is in C++20... – NoSenseEtAl Aug 26 '20 at 23:12

1 Answers1

15

Concluding from Eric Niebler's (and other authors') numerous answers (during talks and on his github comments), they (the committee and the authors) simply ran out of time. The proposal was already large (notice the fact that it heavily referenced the <concepts> proposals) and adding even more to it would spawn a risk of not shipping anything from <ranges> to .

Parallel overloads are not the only things that missed the boat. Various views are absent (both due to lack of time and some semantical problems (looking at you, zip)), there are zero actions and nothing from <numeric> was rangified.

<ranges> will surely evolve further, but polishing the proposals requires time. We can't predict the future, but I would be seriously surprised if <ranges> didn't grow bigger with .

Fureeish
  • 12,533
  • 4
  • 32
  • 62