Hello Jimmy,

We 've been experimenting with that in HPX (a C++ Standard Library for Concurrency & Parallelism) for quite a while now. We have implemented all the algorithms with execution policies. You can check them here (use cases/tests):

https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms

There is also this talk on CppNow 2021 that I gave and presents the challenges imposed by this venture:

https://www.youtube.com/watch?v=gA4HaQOlmSY

Just two comments on your email post.

  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​.

  1. Your sample code uses only std::execution::seq​ but your comment suggest that you wanted to use std::execution::par​ on the last line. Is that correct?
Best regards,

Giannis Gonidelis
Research Assistant
STE||AR Group - CCT
Louisiana State University





From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of JIMMY HU via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Tuesday, December 7, 2021 6:00 AM
To: New proposal discussion <std-proposals@lists.isocpp.org>
Cc: JIMMY HU <s103360021@gmail.com>
Subject: [std-proposals] std::ranges APIs with Execution Policy
 
Hi,

I am trying to propose new APIs (in header <algorithm>) for integrating std::ranges with execution policy parameters. The following description focuses on std::ranges::for_each case.

I've checked the document of std::for_each (https://en.cppreference.com/w/cpp/algorithm/for_each) and std::ranges::for_each (https://en.cppreference.com/w/cpp/algorithm/ranges/for_each). std::for_each provides an overloading with ExecutionPolicy as the first argument, to increase consistency and usability of execution policy parameters, I think that execution policy can be added into std::ranges::for_each function and the following overloading structure can be considered.

template< class ExecutionPolicy, std::input_iterator I, std::sentinel_for<I> S, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<I, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<I, Fun>
          for_each( ExecutionPolicy&& policy, I first, S last, Fun f, Proj proj = {} );

template< class ExecutionPolicy, ranges::input_range R, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<ranges::iterator_t<R>, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<ranges::borrowed_iterator_t<R>, Fun>
          for_each( ExecutionPolicy&& policy, R&& r, Fun f, Proj proj = {} );

The usage examples:

std::vector<int> nums{3, 4, 2, 8, 15, 267};
auto print = [](const auto& n) { std::cout << ' ' << n; };
namespace ranges = std::ranges;
ranges::for_each(std::execution::seq, std::as_const(nums), print);    //  the usage with std::execution::sequenced_policy
ranges::for_each(std::execution::seq, std::as_const(nums), print);    //  the usage with std::execution::parallel_policy

I want to hear some feedback about this idea. The formal draft of this feature is working on. Thank you so much.

Sincerely,

--
Jimmy Hu