Created on 2020-08-18.00:00:00 last changed 12 months ago
Proposed resolution:
This wording is relative to N4861.
Modify [thread.thread.constr] as indicated:
template<class F, class... Args> explicit thread(F&& f, Args&&... args);-3- Constraints: remove_cvref_t<F> is not the same type as thread.
-4- Mandates: The following are all true:
(4.1) — is_constructible_v<decay_t<F>, F>,
(4.2) — (is_constructible_v<decay_t<Args>, Args> && ...), and
(4.3) — is_move_constructible_v<decay_t<F>>,
(4.4) — (is_move_constructible_v<decay_t<Args>> && ...), and(4.5) — is_invocable_v<decay_t<F>, decay_t<Args>...>.
-5- Preconditions: decay_t<F> and each type in decay_t<Args> meet the Cpp17MoveConstructible requirements.
Modify [thread.jthread.cons] as indicated:
template<class F, class... Args> explicit jthread(F&& f, Args&&... args);-3- Constraints: remove_cvref_t<F> is not the same type as jthread.
-4- Mandates: The following are all true:
(4.1) — is_constructible_v<decay_t<F>, F>,
(4.2) — (is_constructible_v<decay_t<Args>, Args> && ...), and
(4.3) — is_move_constructible_v<decay_t<F>>,
(4.4) — (is_move_constructible_v<decay_t<Args>> && ...), and(4.5) — is_invocable_v<decay_t<F>, decay_t<Args>...> || is_invocable_v<decay_t<F>, stop_token, decay_t<Args>...>.
-5- Preconditions: decay_t<F> and each type in decay_t<Args> meet the Cpp17MoveConstructible requirements.
Modify [futures.async] as indicated:
template<class F, class... Args> [[nodiscard]] future<invoke_result_t<decay_t<F>, decay_t<Args>...>> async(F&& f, Args&&... args); template<class F, class... Args> [[nodiscard]] future<invoke_result_t<decay_t<F>, decay_t<Args>...>> async(launch policy, F&& f, Args&&... args);-2- Mandates: The following are all true:
(2.1) — is_constructible_v<decay_t<F>, F>,
(2.2) — (is_constructible_v<decay_t<Args>, Args> && ...), and
(2.3) — is_move_constructible_v<decay_t<F>>,
(2.4) — (is_move_constructible_v<decay_t<Args>> && ...), and(2.5) — is_invocable_v<decay_t<F>, decay_t<Args>...>.
-3- Preconditions: decay_t<F> and each type in decay_t<Args> meet the Cpp17MoveConstructible requirements.
[ 2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP. ]
[ 2020-09-02; Reflector prioritization ]
Set priority to 0 and status to Tentatively Ready after five votes in favour during reflector discussions.
[ 2020-08-26; Reflector discussion ]
Jonathan noticed that the wording for std::async is affected by exactly the same unnecessary move-constructible requirements. The proposed wording has been updated to cope for that as well.
I think this was upgraded to Mandates because C++17 and earlier had "F and each Ti in Args shall satisfy the Cpp17MoveConstructible requirements." And for those, I think the requirement was attempting to make the subsequent decay-copy valid. However, the 'Mandating the standard library' papers added is_constructible requirements which already serve that purpose; std::(j)thread has no reason to move the elements after they have been decay-copy'd to transfer to the launched thread.
History | |||
---|---|---|---|
Date | User | Action | Args |
2023-11-22 15:47:43 | admin | set | status: wp -> c++23 |
2020-11-09 21:40:50 | admin | set | messages: + msg11589 |
2020-11-09 21:40:50 | admin | set | status: ready -> wp |
2020-09-02 17:45:06 | admin | set | messages: + msg11468 |
2020-09-02 17:45:06 | admin | set | status: new -> ready |
2020-08-26 16:06:35 | admin | set | messages: + msg11462 |
2020-08-23 16:12:26 | admin | set | messages: + msg11458 |
2020-08-18 00:00:00 | admin | create |