On 12/2/24 13:20, Jonathan Wakely wrote:
>
>
> On Sun, 1 Dec 2024 at 19:28, Andrey Semashev via Std-Proposals <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> 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>)
>
>
> Why would you expect it to work?

Because that's how functions and member functions work. Personally, I
always take address of a function because that's what actually is being
used, and taking address of a member function is mandatory anyway.

Namespace-scope function objects are uncommon (or, at least, not as
common as normal functions), so any difference in usage in the same
contexts as normal functions will be unexpected. You could get away with
function objects that are not expected to be passed as arguments and
always called directly (e.g. std::ranges::begin), but this proposal is
different.