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

### 2407. `packaged_task(allocator_arg_t, const Allocator&, F&&)` should neither be constrained nor `explicit`

Section: 32.9.10.2 [futures.task.members] Status: C++17 Submitter: Stephan T. Lavavej Opened: 2014-06-14 Last modified: 2017-07-30

Priority: Not Prioritized

View all other issues in [futures.task.members].

View all issues with C++17 status.

Discussion:

LWG 2097's resolution was slightly too aggressive. It constrained `packaged_task(allocator_arg_t, const Allocator&, F&&)`, but that's unnecessary because `packaged_task` doesn't have any other three-argument constructors. Additionally, it's marked as `explicit` (going back to WP N2798 when `packaged_task` first appeared) which is unnecessary.

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

Back to LWG; not an SG1 issue.

[2015-05 Lenexa]

STL improves proposed wording by restoring the constraint again.

Proposed resolution:

This wording is relative to N3936.

1. Change 32.9.10 [futures.task] p2, class template `packaged_task` as indicated:

   >     template <class F>
   >     explicit packaged_task(F&& f);
   >     template <class F, class Allocator>
   >     explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f);

2. Change 32.9.10.2 [futures.task.members] as indicated:

   >     template <class F>
   >     packaged_task(F&& f);
   >     template <class F, class Allocator>
   >     explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f);

   > > […]

   > > -3- Remarks: These constructors shall not participate in overload resolution if `decay_t<F>` is the same type as `std::packaged_task<R(ArgTypes...)>`.