On Wed, 2025-07-16 at 02:14 -0400, Jason McKesson via Std-Proposals
wrote:
> On Tue, Jul 15, 2025 at 9:59 AM Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > I recall discussing this with other people at some point; not sure
> > if
> > there's already an existing proposal for it.
> >
> > I think it's well-motivated; we have function objects for
> > std::plus/+
> > and other sort of builtin things that you cannot (always) for a
> > function pointer to, and this fits right in with those.
> >
> > However, std::construct is a bad name. You're basically making a
> > callable type in the style of std::plus and std::less; all of those
> > are named using a noun, presumably because they are not functions.
> > std::construct sounds dangerously close to std::construct_at;
> > there's
> > some potential for confusion.
> >
> > Something like std::construction or std::constructor would be more
> > fitting for that type.
>
> On the bikeshedding point,

I'll be happy with any name provided it's standardized, but I cannot
resist a naming argument.


> `std::construct` sounds like it should be
> related to `std::construct_at`, but it very much isn't.


Why not? std::construct<T>(x, y) constructs a T from an x and a y.
std::construct_at<T>(location, x, y) constructs a T from an x and a y
at the given location.


> You're getting
> a callable that represents the object's constructor, so
> `std::constructor` fits right alongside `std::function` and
> `std::mem_fn`.


I also agree with that. And given that std::construct<T> is likely to
be used on its own and not immediately be called, perhaps more weight
should be given to that use case.