It would be easier to add the emplacement adapters as standalone CPOs - as
I mentioned in my primary answer. It avoids changing so many classes, and
it is more scalable.

how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

در تاریخ یکشنبه ۲۱ دسامبر ۲۰۲۵،‏ ۱۵:۳۰ <
std-discussion-request_at_[hidden]> نوشت:

> Send Std-Discussion mailing list submissions to
> std-discussion_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> or, via email, send a message with subject or body 'help' to
> std-discussion-request_at_[hidden]
>
> You can reach the person managing the list at
> std-discussion-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Discussion digest..."
> Today's Topics:
>
> 1. Re: Std-Discussion Digest, Vol 81, Issue 8 (Rasheeq Azad)
>
>
>
> ---------- Forwarded message ----------
> From: Rasheeq Azad <rasheeqhere_at_[hidden]>
> To: std-discussion_at_[hidden]
> Cc:
> Bcc:
> Date: Sat, 20 Dec 2025 08:00:00 -0500
> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 8
> On Wed, Dec 17, 2025 at 2:18 PM Brian Bi via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> > So, I think the only way to actually implement the spec is to add an
> extra constructor like the standard library devs have done. This does
> appear to be an issue with the spec since it breaks user-defined
> specializations of `optional` like Rashee[q] points out, and LWG should
> decide what to do about it, e.g.:
>
> If there's two of us, I feel confident enough to draft an issue to
> LWG. I'll try to get to it soon.
>
> > ban user-defined specializations of `optional`?
>
> I hope not!
>
> > recommend to LEWG that they add the necessary constructor to the public
> interface?
>
> In my opinion, everywhere that the standard has an in_place_t
> constructor or emplace member function, it should instead/also have a
> function taking an invocable. That seems like the "obvious" way to
> represent "an arbitrary initializer". I wonder why this wasn't done in
> the first place?
>
> - Rasheeq Azad
>
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>