On Mon, 2 Dec 2024 at 11:53, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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 >);
>

std::bind_front is not an addressable function, so this has unspecified
behaviour, and might even be ill-formed.