Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++14 status.

2097.packaged_task constructors should be constrained

Section: 32.10.10.2[futures.task.members]Status:C++14Submitter: Jonathan WakelyOpened: 2011-11-02Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [futures.task.members].

View all issues withC++14 status.

Discussion:

With the proposed resolution of2067⁽ⁱ⁾, this no longer selects thecopy constructor:

std::packaged_task<void()> p1;std::packaged_task<void()> p2(p1);

Instead this constructor is a better match:

template <class F> explicit packaged_task(F&& f);

This attempts to package apackaged_task, which internally tries tocopyp2, which fails because the copy constructor is deleted. For atleast one implementation the resulting error message is much lesshelpful than the expected "cannot call deleted function" because ithappens after instantiating several more templates rather than in thecontext where the constructor is called.

I believe the solution is to constrain to the template constructors sothe template argumentF cannot be deduced as (possiblycv)packaged_task& orpackaged_task. It could be argued this constraint is already implied becausepackaged_task is not copyable and the template constructors require that "invoking a copy off shall behave the same as invokingf".

Daniel points out that the variadic constructor ofstd::threaddescribed in 32.4.3.3[thread.thread.constr] has a similar problem and suggests a similar wording change, which has been integrated below.

An alternative is to declarethread(thread&) andpackaged_task(packaged_task&) as deleted.

[2012, Portland]

This issue appears to be more about library specification than technicalconcurrency issues, so should be handled in LWG.

[2013, Chicago]

Move to Immediate resolution.

Howard volunteered existing implementation experience with the first change, and saw no issue that the second would introduce any new issue.

Proposed resolution:

This wording is relative to the FDIS.

1. Insert a new Remarks element to 32.4.3.3[thread.thread.constr] around p3 as indicated:

   template <class F, class ...Args> explicit thread(F&& f, Args&&... args);

   -3-Requires:F and eachTi inArgs shall satisfy theMoveConstructible requirements.INVOKE(DECAY_COPY ( std::forward<F>(f)),DECAY_COPY (std::forward<Args>(args))...) (20.8.2) shall be a valid expression.

   -?-Remarks: This constructor shall not participate in overload resolution ifdecay<F>::type is the same type asstd::thread.

2. Insert a new Remarks element to 32.10.10.2[futures.task.members] around p2 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);

   -2-Requires:INVOKE(f, t1, t2, ..., tN, R), wheret1, t2, ..., tN are values of the correspondingtypes inArgTypes..., shall be a valid expression. Invoking a copy off shall behave the same as invokingf.

   -?-Remarks: These constructors shall not participate in overload resolution ifdecay<F>::type is the same type asstd::packaged_task<R(ArgTypes...)>.