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

> 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.
>

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.