On 12/2/24 14:00, Avi Kivity wrote:
> On Sun, 2024-12-01 at 22:28 +0300, Andrey Semashev via Std-Proposals wrote:
>> On December 1, 2024 9:43:24 PM Avi Kivity <avi_at_[hidden]
>> <mailto:avi_at_[hidden]>> wrote:
>>
>>> On Sun, 2024-12-01 at 21:25 +0300, Andrey Semashev wrote:
>>>> On December 1, 2024 7:57:45 PM Avi Kivity <avi_at_[hidden]
>>>> <mailto:avi_at_[hidden]>> 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>)
>>
>
>
> It's true for similar constructs:
>
> std::ranges::transform(&std::bind_front(fn, 3));
>
> also won't work.

Here, std::bind_front is a function call that returns an rvalue, that's
why it won't work. It is different from what I was showing. You can take
address of std::bind_front itself, if you need (though
std::range::transform is not applicable in this case).

foo(&std::bind_front< void(*)(int), int >);