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.
packaged_task(allocator_arg_t, const Allocator&, F&&)
should neither be constrained nor
explicit
Section: 32.10.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 other active issues in [futures.task.members].
View all other issues in [futures.task.members].
View all issues with C++17 status.
Discussion:
LWG 2097(i)'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.
Change 32.10.10 [futures.task] p2, class template packaged_task
as indicated:
template <class F> explicit packaged_task(F&& f); template <class F, class Allocator>explicitpackaged_task(allocator_arg_t, const Allocator& a, F&& f);
Change 32.10.10.2 [futures.task.members] as indicated:
template <class F> packaged_task(F&& f); template <class F, class Allocator>explicitpackaged_task(allocator_arg_t, const Allocator& a, F&& f);[…]
-3- Remarks: These constructors shall not participate in overload resolution ifdecay_t<F>
is the same type asstd::packaged_task<R(ArgTypes...)>
.