This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 3049. Missing wording allowing algorithms to use copies of function objects as substitutes for their parameters

Section: 25.2 [algorithms.requirements] Status: Open Submitter: Jared Hoberock Opened: 2017-12-04 Last modified: 2020-09-06

Priority: 3

View all other issues in [algorithms.requirements].

View all issues with Open status.

Discussion:

When designing the parallel algorithms library, we intended for parallel algorithms to copy their function objects parameters when it is possible and useful to do so, but there doesn't appear to be any wording to enable that latitude. To the contrary, algorithm specifications refer to their function object parameters by name, implying that a copy of the parameter may not be used as a substitute.

This was noticed when Billy O'Neal observed that parallel `generate()` did not share parallel `for_each()` and `for_each_n()`'s special requirement for a `CopyConstructible` user-provided function object.

This `CopyConstructible Function` requirement was added to relax legacy `for_each()`'s `MoveConstructible Function` requirement to allow parallel implementations to make copies as necessary. All parallel algorithms need similar permissions, but a strong requirement for `CopyConstructible` in all algorithms is too restrictive.

What we require is to allow algorithm implementations to use copies of function objects as substitutes for their original parameters, while not requiring that all function object parameters be copyable.

Casey Carter noted that 25.2 [algorithms.requirements] p8 grants permission to all algorithms to copy their function object parameters. However, this paragraph is not normative and does not indicate how the algorithm is allowed to use such copies. Additionally, it does not specify which algorithm parameters are the ones called out as function objects. For example, 25.7.7 [alg.generate] refers to `gen` as a function object, but 25.6.4 [alg.foreach] does not refer to `f` as a function object. All the other types of callable algorithm parameters (i.e. `Predicate`, `BinaryPredicate`, `Compare`, `UnaryOperation`, `BinaryOperation`, `BinaryOperation1`, and `BinaryOperation2`) are defined to be function objects in 25.2 [algorithms.requirements] and 25.3.2 [algorithms.parallel.user]. This list intentionally omits `Function` and `Generator` by design.

A potential resolution would introduce normative wording to explicitly allow algorithms to use copies of function object parameters as substitutes for their function object parameters, and remove ambiguity in algorithm specifications about which parameters are function objects.

[2018-01; Priority set to 3 after mailing list discussion]

[2018-3-14 Wednesday evening issues processing; move to Open]

We thought that the notes in [alg.foreach]/1 and /11 should be unwrapped as well. Bryce to work with Jared on updated wording.

Proposed resolution:

This wording is relative to N4713.

1. Modify 25.2 [algorithms.requirements] as indicated:

   > -8- [Note: Unless otherwise specified, algorithms that take function objects as arguments are permitted to copy those function objects freely. When an algorithm's specification requires the invocation of a function object parameter, such a copy may be invoked as a substitute for the original function object parameter. [Note: This implies that copyable user-supplied function objects should not rely on their identity. Programmers for whom object identity is important should consider using a wrapper class that points to a noncopied implementation object such as `reference_wrapper<T>` (20.14.6 [refwrap]), or some equivalent solution. — end note]

2. Modify 25.6.4 [alg.foreach] as indicated:

   >     template<class InputIterator, class Function>
   >       constexpr Function for_each(InputIterator first, InputIterator last, Function f);

   > > […]

   > > -2- Effects: Applies the function object `f` to the result of dereferencing every iterator in the range `[first, last)`, […]

   > > […]

   >     template<class ExecutionPolicy, class ForwardIterator, class Function>
   >       void for_each(ExecutionPolicy&& exec,
   >                     ForwardIterator first, ForwardIterator last,
   >                     Function f);

   > > -6- Requires: `Function` shall meet the requirements of `CopyConstructible`.

   > > -7- Effects: Applies the function object `f` to the result of dereferencing every iterator in the range `[first, last)`. […]

   > > […]

   >     template<class InputIterator, class Size, class Function>
   >     constexpr InputIterator for_each_n(InputIterator first, Size n, Function f);

   > > […]

   > > -13- Effects: Applies the function object `f` to the result of dereferencing every iterator in the range `[first, first + n)` in order. […]

   > > […]

   >     template<class ExecutionPolicy, class ForwardIterator, class Size, class Function>
   >       ForwardIterator for_each_n(ExecutionPolicy&& exec, ForwardIterator first, Size n,
   >                                  Function f);

   > > -16- Requires: `Function` shall meet the requirements of `CopyConstructible`.

   > > […]

   > > -18- Effects: Applies the function object `f` to the result of dereferencing every iterator in the range `[first, first + n).` […]

   > > […]