On Sat, Jul 20, 2024 at 12:31 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Saturday 20 July 2024 09:20:43 GMT-7 Thiago Macieira via Std-Proposals
> wrote:
> > You need to convince them by writing in your paper that yours is required
> > because one or both of these conditions are true:
> >
> > a) P2025 is unlikely to see adoption in the near and medium term (or ever),
> > for technical reasons that cannot be easily solved
> >
> > b) the need is so pressing that) a solution is needed *now*
>
> Sorry, adding to (b)
>
> ... and this functionality can only be implemented by the Standard Library
> because any successful library-only implementation would necessarily incur UB
> (read: it requires compiler help).
>
> In other words, you must shown your own attempts at implementing this are UB.
>
> Because if you can implement it without UB in a simple header but P2025 is
> just around the corner, then we don't need the stop gap in the Standard
> Library. Those who need it can just use this simple header right now, while
> waiting for P2025.
>
> There's value in standardising things that anyone can write (like
> std::construct_at, for example), but only if there's no replacement in the
> horizon that we're already aware of.

Note that `construct_at` wasn't standardized until it could do
something you couldn't do otherwise: construct objects in memory at
compile-time.

`construct_at` is also illustrative here. The constexpr version of it
is basically a hack for not being able to do placement-new at compile
time. Or more specifically, that doing placement-new would require
void* conversions that aren't normally possible in compile-time code.
`construct_at` was a functional solution to that problem. But
subsequent implementation experience with constexpr coding and such
demonstrated that the kinds of `void*` conversions needed to do
placement-new could be done in a way that compilers could implement.

Which is why constexpr placement-new is going into C++26.

I don't think this `std::factory` business is the same kind of thing.
The issues with P2025 aren't really implementation questions; it's
more about what the right syntax and behavior ought to be.