Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ranges] Considering adding ExecutionPolicy parameters into std::ranges::for_each #5132

Closed
Jimmy-Hu opened this issue Dec 1, 2021 · 4 comments
Closed

[ranges] Considering adding ExecutionPolicy parameters into std::ranges::for_each #5132

Jimmy-Hu opened this issue Dec 1, 2021 · 4 comments

Comments

@Jimmy-Hu
Copy link

Jimmy-Hu commented Dec 1, 2021 •
edited

Hi,

I've checked there is a function overloading with ExecutionPolicy parameters in std::for_each:

template< class ExecutionPolicy, class ForwardIt, class UnaryFunction2 >
void for_each( ExecutionPolicy&& policy, ForwardIt first, ForwardIt last, UnaryFunction2 f );

I think that the execution policy parameters can also 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 = {} );

An advantage of this design is to integrate parallel algorithm into ranges::for_each function.
@JohelEGP
Copy link
Contributor

JohelEGP commented Dec 2, 2021

The issue sounds like a proposal. Adding new overloads to ranges::for_each is not an editorial issue. I suggest you read the first section of the README for more information on what that might mean.

@Jimmy-Hu
Copy link
Author

Jimmy-Hu commented Dec 2, 2021 •
edited

@JohelEGP Thank you for the prompt reply. I've checked the How to submit a new issue/defect report and an initial message to std-discussion have been posted. So the next step is to follow the instruction in "How to submit a core language or standard library issue" section? It's my first time to propose new proposal. Please let me know if there is any misunderstanding. Thank you so much.

@JohelEGP
Copy link
Contributor

JohelEGP commented Dec 2, 2021

A linked webpage also has this: https://isocpp.org/std/submit-a-proposal.

@jwakely
Copy link
Member

jwakely commented Dec 2, 2021

You need to submit a proposal. The issue process is for fixing defects. This is not a defect. The lack of parallel overloads for the ranges algo is intentional, not a mistake.

Closing as this is not editorial.

@jwakely jwakely closed this as completed Dec 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jwakely @Jimmy-Hu @JohelEGP