śr., 16 lip 2025 o 11:04 Avi Kivity via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> 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.
>

Could a better name be: `make_value<T>`? it will be similar to other
`make_*` functions and explicitly say what it does.

>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals