We should have a type that pin<> (or senders/receivers) can be
constructed from, so we can pass them along stuff like std::apply or
the proposed std::construct.

On Tue, 2024-12-03 at 13:10 +0000, Gašper Ažman via Std-Proposals
wrote:
> 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.