Date: Sat, 20 Dec 2025 08:00:00 -0500
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_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
Received on 2025-12-20 13:01:06
