Proposed resolution:

This wording is relative to N4988.

1. Modify [futures.task.members] as indicated:

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

   -2- Constraints: remove_cvref_t<F> is not the same type as packaged_task<R(ArgTypes...)>.

   -3- Mandates: is_invocable_r_v<R, Fdecay_t<F>&, ArgTypes...> is `true`.

   -4- Preconditions: Invoking a copy of `f` behaves the same as invoking `f`.

   -5- Effects: Constructs a new `packaged_task` object with a stored task of type decay_t<F> and a shared state . Initializes and initializes the object's stored task with std::forward<F>(f).

[ Wrocław 2024-11-23; Status changed: Voting → WP. ]

[ 2024-10-09; LWG telecon: Move to Ready ]

[ 2024-10-02; LWG telecon ]

Clarify that "of type decay_t<F>" is supposed to be specifying the type of the stored task.

[ 2024-10-02; Jonathan provides improved wording ]

Drop preconditions as suggested on reflector.

[ 2024-10-02; Reflector poll ]

Set priority to 3 after reflector poll.

"Fix preconditions, `f` doesn't need to be invocable, we only invoke the copy."

Currently, [futures.task.members]/3 states:

Mandates: is_invocable_r_v<R, F&, ArgTypes...> is `true`.

However, in mainstream implementations (libc++, libstdc++, and MSVC STL), the stored task object always has a cv-unqualified type, and thus the cv-qualification is unrecognizable in `operator()`.

Since [func.wrap.func.con] uses a decayed type, perhaps we should also so specify for `std::packaged_task`.