On 12/2/24 13:20, Jonathan Wakely wrote:
>
>
> On Sun, 1 Dec 2024 at 19:28, Andrey Semashev via Std-Proposals <std-
> proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>> wrote:
>
> On December 1, 2024 9:43:24 PM Avi Kivity <avi@scylladb.com
> <mailto: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
> <mailto: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>)
>
>
> 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.
But it's not allowed for functions and function templates in the standard library. See [namespace.std] p6.
So I don't see why it should work for the proposed std::construct.
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.
Many function objects in the standard library *are* allowed to be passed as arguments, that's part of the rationale for P3136.
That includes ranges::begin, which is a CPO and:
"The type of a customization point object, ignoring cv-qualifiers, shall model semiregular"
You are describing idioms and rules which contradict the standard.