Date: Tue, 3 Dec 2024 13:10:05 +0000
pin<> is an archetype of "nonmovable" - and with sender/receiver and its
operation states, "nonmovable" is actually super common.
On Tue, Dec 3, 2024 at 11:07 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi Avi,
>
>
>
> Is this a contradiction?
>
>
>
> "The problem happen anywhere you use perfect forwarding."
>
> "Just because one class is broken wrt perfect forwarding"
>
>
>
>
>
>
> That's a peculiarity of pin<> and isn't related to construct<>.
>
> The problem with pin<> will happen anywhere you use perfect forwarding,
> for example you can't use it with std::apply(). Just because one class is
> broken wrt perfect forwarding doesn't mean we can't use perfect forwarding
> any more.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
operation states, "nonmovable" is actually super common.
On Tue, Dec 3, 2024 at 11:07 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi Avi,
>
>
>
> Is this a contradiction?
>
>
>
> "The problem happen anywhere you use perfect forwarding."
>
> "Just because one class is broken wrt perfect forwarding"
>
>
>
>
>
>
> That's a peculiarity of pin<> and isn't related to construct<>.
>
> The problem with pin<> will happen anywhere you use perfect forwarding,
> for example you can't use it with std::apply(). Just because one class is
> broken wrt perfect forwarding doesn't mean we can't use perfect forwarding
> any more.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-12-03 13:10:18