On Tue, Dec 7, 2021 at 6:59 PM JIMMY HU via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi Giannis,
>
> Thank you for your reply and providing the great references.
>
> I've checked the hpx library, the similar declaration is already in line 175~179 in hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms/for_each.hpp.
>
> Reply to your question:
>
> > 1. You propose std::input_iterator and ranges::input_range as the prospective API. What would the benefit be on parallelizing the ranges algorithms if the supported iterator was just an InputIt? AFAIAC you cannot impose parallelization without a RandomAccessIterator.
>
> The usages of std::input_iterator and ranges::input_range is referenced from the existing std::ranges::for_each call signature (https://en.cppreference.com/w/cpp/algorithm/ranges/for_each), I want to keep the constraints of the remain parameters constantly.

OK, but... how?

The parallel algorithms didn't change their iterator requirements on a
whim. They changed them to make parallelism possible. Forward
iterators are iterators across a sequence of values that continue to
exist after the iterator has moved on. Input iterators *are not*.
They're specifically allowed to destroy any referenced element after
the iterator is incremented. Copying an input iterator does not create
two distinct iterators that can be incremented and worked with
independently. And so forth.

So how can you have a parallel version of `for_each` operate on pure
input iterators? How can different threads access different elements
in the sequence, when the iterator is permitted to destroy and reclaim
those elements once it is incremented?