What's pin<int>?

Don't all helpers that rely on perfect forwarding suffer from this? e.g. std::bind(), std::bind_front(), emplace()?

Shouldn't we rename "perfect forwarding" to "imperfect forwarding" if it isn't able to perfectly forward some types?

On Sun, 2024-12-01 at 19:31 +0000, Gašper Ažman via Std-Proposals wrote:
The only reason to standardize this would be if somehow this function was magically blessed to perfectly forward constructor arguments to the constructor, including non-movable pr-values:

MyType(pin<int>)

is not constructible using std:construct without special language support.

On Sun, Dec 1, 2024 at 7:28 PM Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On December 1, 2024 9:43:24 PM Avi Kivity <avi@scylladb.com> wrote:

> On Sun, 2024-12-01 at 21:25 +0300, Andrey Semashev wrote:
>> On December 1, 2024 7:57:45 PM Avi Kivity <avi@scylladb.com> wrote:
>>
>>> On Sun, 2024-12-01 at 19:11 +0300, Andrey Semashev via Std-
>>> Proposals
>>> wrote:
>>
>>> Or we can make it a
>>> niebloid.
>>
>> Sorry, I don't know what this means.
>
>
> A technique used in std::ranges to avoid such pointers-to-functions.
>
> template <typename T>
> struct _Impl_construct
>    template <typename... Args>
>    static T operator()(Args... args) { return
> T(std::forward<Args>(args)...); }
> };
>
> template <typename T>
> inline _Impl_construct construct;

This would make taking address of std::construct not work, which is unexpected.

std::ranges::transform(&std::construct<T>)