Date: Thu, 18 Dec 2025 03:56:59 +0330
I can see several problems with that snippet. `std` namespace qualifiers
are missing every here and there. Aggregates can not use round bracket
constructors, the specialization doesn't need the generic variadic template
constructor(especially the `initializer_list`). Your `in_place`
constructors just need the simpler form. In case of RVO/NRVO, direct
initialization requires availability of move/copy constructor(even though
elided). Unfortunately I have difficulty accessing compiler explorer for a
variety of reasons. Finally, I don't understand the rationale behind
specializing standard library templates - which is ill-formed in general,
and for `optional` specifically. Finally, I recommend a reading of
"boost.tribool" docs. While `optional<bool>` doesn't seem to need
optimization IMHO. The baseline implementation would require two bytes, but
optimized builds may shorten it to 1. In either case, it doesn't seem to be
the bottle neck.
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 16 (Brian Bi)
>
>
>
> ---------- Forwarded message ----------
> From: Brian Bi <bbi5291_at_[hidden]>
> To: std-discussion_at_[hidden]
> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
> Bcc:
> Date: Wed, 17 Dec 2025 17:37:53 -0500
> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 16
>
>
> On Wed, Dec 17, 2025 at 5:31 PM Farid Mehrabi via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> You're missing a `bind`. You have to:
>>
>> 1. bind `ref(this->value)` to the input `f` to get a proper invocable. A
>> capturing lambda will do as well.
>>
>
> I skipped the `bind` by using nullary invocables in my example instead of
> unary ones (to simplify the example). I don't think it makes any difference
> to my point.
>
>
>>
>> 2. Next step is to wrap the bind/lambda in an emplacer object to get a
>> "convertible".
>>
>> 3. The convertible is then passed to proper constructor/emplace function.
>>
>
> You pass it to the desired constructor of `std::optional<U>`, but the
> important thing here is that you do not get to directly select which
> constructor of `U` gets used. The `in_place_t` constructor of
> `std::optional<U>` does overload resolution (using the arguments after the
> `in_place_t`) to select a constructor of `U`. In the normal course of
> things, the copy or move constructor of `U` gets selected, its parameter
> binds to the emplacer argument, and the copy/move constructor itself gets
> elided (see CWG2327/P2828 for an explanation). The example I showed
> demonstrates how it might be possible that a different constructor of `U`
> gets selected, and the emplacer doesn't end up getting used at all, even
> though you've passed it to `std::optional<U>`'s constructor.
>
> I've put in the work of showing a complete self-contained godbolt example
> to prove my point. If you can implement a function that takes an arbitrary
> callable (that returns `Immovable2` by value), and uses that callable to
> construct an `optional<Immovable2>`, please show a complete self-contained
> godbolt example.
>
>
>>
>> You keep moving the goal post. `transform` takes a unary invocable. It
>> doesn't have to do anything with variadic templates except for calling the
>> constructor with a single emplacer object. If the input invocable triggers
>> diagnostics, the user code is ill-formed. `immovable` can have as many
>> constructors as user demands. The one that is used in the lambda sent to
>> `transform` must be available in the context of definition of lambda:
>> ```cpp
>> optional<T> opt;
>> opt.transform
>> ( [](auto& v)
>> { return immobile{v, xxx};} );
>> ```
>> Wether or not `immobile{v, xxx}` is a valid expression, has nothing to do
>> with standard library definition. It's the responsibility of user code.
>>
>> As mentioned earlier, the input unary invocably must either return a
>> value, or a reference to copy/move constructible value; otherwise the user
>> code is ill-formed. That's the only requirement for `transform`.
>>
>> 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 12 (Brian Bi)
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Brian Bi <bbi5291_at_[hidden]>
>>> To: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>> Cc: std-discussion_at_[hidden]
>>> Bcc:
>>> Date: Wed, 17 Dec 2025 17:00:28 -0500
>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 12
>>>
>>>
>>> On Wed, Dec 17, 2025 at 4:24 PM Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>> wrote:
>>>
>>>> Here comes the implementation as well:
>>>> ```cpp
>>>> If (not this->has_value())
>>>> return nullopt;
>>>> /*define Local struct emplacer_t as before */
>>>> return optional<U>
>>>> { in_place, emplacer_t{ fn } };
>>>> ```
>>>> The `in_place_t` constructor template can be used to explicitly
>>>> initialize an instance of `optional`. No extra constructor is needed.
>>>>
>>>> You're original problem was to use an "invocable" as an input to a
>>>> public standard constructor. I gave you the emplacer idiom as the solution
>>>> to replace an "invocable" with a "convertible" in my initial answer,
>>>> assuming that you'd figure the proper constructor to apply the convertible.
>>>> In this post I demonstrated the proper constructor too. I hope you can
>>>> connect the dots at this point.
>>>>
>>>
>>> Okay, you want to make me do the work here. Fine.
>>>
>>> Here's a complete working example of how to use the emplacer idiom to
>>> construct an optional containing an immovable object, where that immovable
>>> object is initialized by calling a function that returns it by value:
>>>
>>> #include <functional>
>>> #include <optional>
>>>
>>> struct Immovable1 {
>>> Immovable1(int) {}
>>> Immovable1(const Immovable1&) = delete;
>>>
>>> static Immovable1 make() { return {1}; }
>>> };
>>>
>>> template <class F>
>>> struct Emplacer {
>>> F&& f;
>>> operator std::invoke_result_t<F>() const {
>>> return std::invoke((F&&)f);
>>> }
>>> };
>>>
>>> template <class F>
>>> std::optional<std::invoke_result_t<F>> makeOptional(F&& f) {
>>> return std::optional<std::invoke_result_t<F>>{std::in_place,
>>> Emplacer{(F&&)f}};
>>> }
>>>
>>> auto o1 = makeOptional(Immovable1::make);
>>>
>>> But let me show you a different value type for which this implementation
>>> doesn't work:
>>>
>>> struct Immovable2 {
>>> Immovable2(int) {}
>>> Immovable2(const Immovable2&) = delete;
>>>
>>> Immovable2(auto&&... args) {
>>> static_assert(sizeof...(args) > 100); // always false
>>> }
>>>
>>> static Immovable2 make() { return {1}; }
>>> };
>>>
>>> auto o2 = makeOptional(Immovable2::make); // triggers the static
>>> assertion
>>>
>>> The reason why this fails is that instead of using the emplacer's
>>> conversion function to initialize the `Immovable2` object, the `optional`
>>> constructor will instantiate and attempt to use the `Immovable2(auto&&...)`
>>> constructor (at which point the static assertion fires because there is
>>> only one argument, not more than 100). So, you see, if the type has a
>>> constructor like this, then the emplacer idiom doesn't work, because that
>>> constructor is "too good" in overload resolution.
>>>
>>> Here's the example on godbolt: https://godbolt.org/z/PzcK9rMah
>>>
>>> I think that I explained this very clearly in one of my previous
>>> messages: "If the type that needs to be constructed has an unconstrained
>>> constructor template, that constructor template will be used and the
>>> emplacer's conversion function will not be used."
>>>
>>>
>>>>
>>>>
>>>> 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!!!
>>>>
>>>> در تاریخ پنجشنبه ۱۸ دسامبر ۲۰۲۵، ۰۰:۲۸ Brian Bi <bbi5291_at_[hidden]>
>>>> نوشت:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 17, 2025 at 3:43 PM Farid Mehrabi via Std-Discussion <
>>>>> std-discussion_at_[hidden]> wrote:
>>>>>
>>>>>> Now you're skipping my response without enough proper attention and
>>>>>> focus.
>>>>>>
>>>>>
>>>>> I think you should take a step back and consider that you did not
>>>>> actually explain how to construct the `optional`. You explained the
>>>>> emplacer idiom, but you didn't show how to use it to implement `transform`.
>>>>> If I haven't understood you, it's because you haven't explained completely.
>>>>>
>>>>> I've actually implemented the monadic operations for `optional`, so I
>>>>> know how to use the emplacer idiom, so I've filled in the blanks in your
>>>>> email, and I've explained why the approach is not perfect. If you meant
>>>>> something different than what I meant, then you should show a working
>>>>> proof-of-concept implementation of `transform`.
>>>>>
>>>>>
>>>>>>
>>>>>> The emplacer object is constructed and explicitly converted by the
>>>>>> impelementation. The point of using emplacer idiom is to replace a function
>>>>>> call with a conversion, so the constructor/`emplace` member of result
>>>>>> object won't need an extra move construction. The result object
>>>>>> `optional<U>` has an explicit and fully specified type, so there will be no
>>>>>> mistakes:
>>>>>> ```cpp
>>>>>> template<typename T, typename F>
>>>>>> auto optioal<T>::transform(F&&)
>>>>>> -> optional<remove_cvref_t<invoke_result_t<F, T&>>>;
>>>>>> ```
>>>>>>
>>>>>
>>>>> How do you construct an `optional<U>` where `U` is immovable and the
>>>>> value of the contained `U` object is obtained by calling some function,
>>>>> call it `f`, that returns `U` by value? Which constructor of `optional<U>`
>>>>> do you call in order to do this?
>>>>>
>>>>> Do you do it like this?
>>>>>
>>>>> return optional<U>(emplacer{...});
>>>>>
>>>>> If so, you are calling constructor #9 shown on cppreference:
>>>>> https://en.cppreference.com/w/cpp/utility/optional/optional
>>>>>
>>>>> And I am telling you that this will not do the right thing if `U`
>>>>> happens to have a constructor like:
>>>>>
>>>>> template <class V>
>>>>> U(V&&);
>>>>>
>>>>>
>>>>>> Result type is already known, So there's only a simple
>>>>>> construction/emplace required for the result. Depending on implementation,
>>>>>> emplacer idiom may or may not be required. Anything `F` returns, will be
>>>>>> stripped off its qualifiers before converting into an `optional`. Compile
>>>>>> fails if proper copy/move constructors are unavailable. Now If your
>>>>>> argument is based on constraining standard library, that'll be a total
>>>>>> reboot not limited to a specific member function of a specific class.
>>>>>>
>>>>>> 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 10 (Brian Bi)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Brian Bi <bbi5291_at_[hidden]>
>>>>>>> To: std-discussion_at_[hidden]
>>>>>>> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>>>>>> Bcc:
>>>>>>> Date: Wed, 17 Dec 2025 15:11:46 -0500
>>>>>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 10
>>>>>>> What you're calling `U` is what I called `T` in my example (the type
>>>>>>> that needs to be constructed).
>>>>>>>
>>>>>>> If the type that needs to be constructed has an unconstrained
>>>>>>> constructor template, that constructor template will be used and the
>>>>>>> emplacer's conversion function will not be used. That is the problem.
>>>>>>>
>>>>>>> On Wed, Dec 17, 2025 at 3:09 PM Farid Mehrabi via Std-Discussion <
>>>>>>> std-discussion_at_[hidden]> wrote:
>>>>>>>
>>>>>>>> I guess you're missinterpreting the usage of `transform`. The
>>>>>>>> output type `U` is deduced from `invoke_result_t<F>`. It has nothing to do
>>>>>>>> with original `T`. If the `F` instance doesn't mutate the original `T`
>>>>>>>> instance, it won't be modified. `T` and `U` don't need to have any
>>>>>>>> relation; the requirment is `invocable<F(T&)>`(`T` reference gets same
>>>>>>>> qualifiers as `this`), and `U` is deduced to `auto{f(t)}`.
>>>>>>>>
>>>>>>>> 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 (Brian Bi)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Brian Bi <bbi5291_at_[hidden]>
>>>>>>>>> To: std-discussion_at_[hidden]
>>>>>>>>> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>>>>>>>> Bcc:
>>>>>>>>> Date: Wed, 17 Dec 2025 14:17:57 -0500
>>>>>>>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue
>>>>>>>>> 8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Dec 16, 2025 at 10:28 AM Farid Mehrabi via Std-Discussion <
>>>>>>>>> std-discussion_at_[hidden]> wrote:
>>>>>>>>>
>>>>>>>>>> There's a very unpopular idiom about this. I call it the
>>>>>>>>>> **emplacer** idiom, which can be used in many different scenarios where the
>>>>>>>>>> proper constructor is not available. It relies on the C++20 mandated direct
>>>>>>>>>> initialization on returned objects:
>>>>>>>>>> ```cpp
>>>>>>>>>> template<invocable<> F>
>>>>>>>>>> struct implacer_t{
>>>>>>>>>> F&& fn;
>>>>>>>>>> operator auto() const
>>>>>>>>>> { return invoke(forward<F>(fn)); };
>>>>>>>>>> }; // ! emplacer
>>>>>>>>>> ```
>>>>>>>>>> The `emplacer_t` class converts any references to invocable
>>>>>>>>>> objects into conversion to returned object, and can be fed to `emplace`
>>>>>>>>>> members of any standard class. It can also be used to call private
>>>>>>>>>> constructors of classes while using `make_unique` or `make_shared`. Usage
>>>>>>>>>> is as simple as:
>>>>>>>>>> ```cpp
>>>>>>>>>> auto fn = []<typname ...A>(A&&...v)
>>>>>>>>>> { return T{forward<A>(v)}; };
>>>>>>>>>>
>>>>>>>>>> my_obj.emplace
>>>>>>>>>> ( emplacer_t
>>>>>>>>>> { bind(fn,args...) } );
>>>>>>>>>> ```
>>>>>>>>>> I just think that the emplacer idiom requires standard
>>>>>>>>>> exposition. A few convenience CPO should be added, that make the idiom
>>>>>>>>>> publicly available to standard library users:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am sure that the standard library implementors know this trick.
>>>>>>>>> The problem is that it doesn't actually let you implement the spec
>>>>>>>>> perfectly. Consider the case of an `optional<T>` where `T` has a
>>>>>>>>> constructor like this:
>>>>>>>>>
>>>>>>>>> template <class U>
>>>>>>>>> T(U&&);
>>>>>>>>>
>>>>>>>>> In other words, there is an implicit conversion from any type to
>>>>>>>>> `T`. Now, if you attempt to construct a `T` using what you've called the
>>>>>>>>> emplacer idiom, this constructor will be called, since it will win overload
>>>>>>>>> resolution compared with the alternative of calling the move constructor of
>>>>>>>>> `T` (with the T&& binding to the T returned by the emplacer's conversion
>>>>>>>>> function).
>>>>>>>>>
>>>>>>>>> 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 Rasheeg points out, and LWG should
>>>>>>>>> decide what to do about it, e.g.:
>>>>>>>>>
>>>>>>>>> - ban user-defined specializations of `optional`?
>>>>>>>>> - recommend to LEWG that they add the necessary constructor to
>>>>>>>>> the public interface?
>>>>>>>>> - modify the spec so that it explicitly uses the emplacer
>>>>>>>>> idiom (thus not requiring support for cases where the emplacer idiom
>>>>>>>>> doesn't work)?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> - `default_emplacer` a CPO that can convert to any object with
>>>>>>>>>> public default constructor via calling the constructor.
>>>>>>>>>> - `emplace_args` embeds a forwarding tuple and returns an object
>>>>>>>>>> constructed from tuple elements upon conversion.
>>>>>>>>>> - `emplace_result` the most generic case that wraps the
>>>>>>>>>> `emplacer_t` class and returns an instance.
>>>>>>>>>> These 3 CPO can help in various situations of emplacement in user
>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> FM.
>>>>>>>>>>
>>>>>>>>>> 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. Implementing std::optional<T>::transform (Rasheeq Azad)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>> From: Rasheeq Azad <rasheeqhere_at_[hidden]>
>>>>>>>>>>> To: Std-Discussion_at_[hidden]
>>>>>>>>>>> Cc:
>>>>>>>>>>> Bcc:
>>>>>>>>>>> Date: Sun, 14 Dec 2025 16:00:00 -0500
>>>>>>>>>>> Subject: [std-discussion] Implementing
>>>>>>>>>>> std::optional<T>::transform
>>>>>>>>>>> In the current draft, [optional.monadic] specifies that
>>>>>>>>>>> std::optional<T>::transform(F &&f) & shall do the following:
>>>>>>>>>>>
>>>>>>>>>>> > Let U be remove_cv_t<invoke_result_t<F, decltype(*val)>>.
>>>>>>>>>>> > Mandates: ...
>>>>>>>>>>> > [Note 1: There is no requirement that U is movable
>>>>>>>>>>> ([dcl.init.general]).
>>>>>>>>>>> > Returns: If *this contains a value, an optional<U> object
>>>>>>>>>>> whose contained value is direct-non-list-initialized with
>>>>>>>>>>> invoke(std::forward<F>(f), *val); otherwise, optional<U>().
>>>>>>>>>>>
>>>>>>>>>>> I'm wondering how this is supposed to be implemented. None of the
>>>>>>>>>>> standard constructors of std::optional<U> directly support
>>>>>>>>>>> initializing the contained object with an invocable. Both GCC
>>>>>>>>>>> libstdc++ [1a] [1b] [1c] and LLVM libc++ [2a] [2b] [2c] get
>>>>>>>>>>> around
>>>>>>>>>>> this by adding an internal-use-only (using a tag type that has a
>>>>>>>>>>> reserved name) constructor to std::optional<T> that takes the
>>>>>>>>>>> invocable and calls it to initialize the contained object. But
>>>>>>>>>>> this
>>>>>>>>>>> means that std::optional<T> relies on the *different
>>>>>>>>>>> specialization*
>>>>>>>>>>> std::optional<U> supporting this nonstandard constructor.
>>>>>>>>>>>
>>>>>>>>>>> As a consequence, neither library can fully cope with me
>>>>>>>>>>> defining my
>>>>>>>>>>> own specialization of std::optional. I hoped this was just an
>>>>>>>>>>> implementation bug and filed an issue with LLVM about it, [3],
>>>>>>>>>>> which
>>>>>>>>>>> contains a code example and my proposed solution (see also on
>>>>>>>>>>> [Godbolt]), but someone else pointed out that my proposed
>>>>>>>>>>> solution
>>>>>>>>>>> also has an edge case. So as far as I can tell right now, it
>>>>>>>>>>> seems
>>>>>>>>>>> impossible to implement std::optional<T>::transform while using
>>>>>>>>>>> only
>>>>>>>>>>> the standard interface of the other specialization
>>>>>>>>>>> std::optional<U>.
>>>>>>>>>>>
>>>>>>>>>>> If this really is the case, then the standard seems to have
>>>>>>>>>>> inadvertently prohibited program-defined specializations of
>>>>>>>>>>> std::optional with the addition of std::optional<T>::transform.
>>>>>>>>>>> I'm
>>>>>>>>>>> hoping to get more eyes on this question. If someone in this list
>>>>>>>>>>> could come up with a way to implement
>>>>>>>>>>> std::optional<T>::transform in a
>>>>>>>>>>> way that permits program-defined specializations (or say with
>>>>>>>>>>> more
>>>>>>>>>>> certainty that it's in fact not possible), that'd be great. Have
>>>>>>>>>>> I
>>>>>>>>>>> found a standard defect?
>>>>>>>>>>>
>>>>>>>>>>> - Rasheeq Azad
>>>>>>>>>>>
>>>>>>>>>>> [1a]:
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L97
>>>>>>>>>>> [1b
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L97[1b>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1490-L1493
>>>>>>>>>>> [1c
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1490-L1493[1c>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1391
>>>>>>>>>>> [2a
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1391[2a>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L369
>>>>>>>>>>> [2b
>>>>>>>>>>> <https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L369[2b>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L925-L927
>>>>>>>>>>> [2c
>>>>>>>>>>> <https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L925-L927[2c>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L1144
>>>>>>>>>>> [3]: https://github.com/llvm/llvm-project/issues/172197
>>>>>>>>>>> [Godbolt]:
>>>>>>>>>>> https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYgATKVpMGoZAFI9AIQuXSS%2BsgJ4BlRugDCqWgFcWDCaRuADJ4DJgAcr4ARpjEIACs8aQADqgKhM4Mnj5%2BAanpTgIhYZEsMXGJdpgOhQxCBEzEBNm%2B/lxVNZn1jQTFEdGxCUkKDU0tue0jPX2l5UMAlHao3sTI7BwWAMyhyD5YANRmm%2B78xCxMBEfYZhoAgls7e5iHx84jxJisVzf3etsMu28ByO7neoWA3zuPweAKeL08yVqYkh9zuuyYCgU%2BxYAE8APpRVBeQ4Adks%2BwA9BT9kx9sliKhgMRWABaLA0MLofYEHHJZ4ASWxeGACAI%2BwA7sYxUR9go%2Bcg8GI8AAvZ4jdAgECoRGZMT7U4/fb7ZAIRr7VRHax3ZLeKK0PDIECG/aYVTJe0KsW4glE2gQQnE1TzfYgc0QIOk8lmEkAEWd3oDfoTvosADY08GjjH9lh6ARMJbnQA/ZNeCCZsmkuObK2o25G13uh2Efba2IXEj7RPl40CEaR/YfAgrBjmy1V%2BP4xOtvnMojEMCQYNoBj96Pkocj7FT30QRfdoPzcfRuNQ2OFqF3fMsd0XAvHK7GoyY2UEDVanUCZHHUu0R/r513m8RwaSiJRBDxMV12NU1iFlRgnDCWgXmzPRj3PGtnW8BhMgHX86Q%2BcDLhrUCiMg0iEPQ6tySpWUmAAN0wLlaSiHF80OAAxDQzAATg4sxbniMxLE2RcfhtO0HSdO4jVoj56HoqVsUwMpYgUZ0VxGRs4O1JE/WDBhUFdNZERDCjBB7aCTw0vt8zdHTP2YP0GG8WhaF0yCDKM1QTLFUNdN1fSB2smSZz0iAAq/ZDNMuPRU0zTZs1zTB8wvOsjWvW9UuOdEXwAOgKgAVR8PgAR28PBCP2PAFDxGLiGApw7UwPF6JBX9SH2QqCrylEjRi7SXTdD0W0ipyIFCPFbzWSDOsKw44rTHqCGDUN6UwIiIHVTVTklYh0BBYrNmwCAVp6iso3PS9625FSsvvdxcqxIJOqe/YeqO7BB0wcrKo26ravqxq8Ga1r2p3LxOtCDIlVVYg8XtEYQSCb44rmnq%2Bt7Vc7PpIam09MLAomhgpqMGaCChnCnFh2IEZq4j3BR479loOaFvTOLltWgiNoQiBWdfd9dsaA7jk%2B075nO4Krpu2iV0YppwSxoDHBILFjC5VACAQWJ9mAEgcRzFKmDoLFUBYQh8wO67%2Btswbp1NWrFJ8TAexi/ZDOMzBTIA0KjU3YhRyYMCELyojQmqfYxMS8yCEg8sw4QiO/0w0KQpugb7P2IsxrESzKzwKgIEd1qxG8V35mDdaiLyksIf0qjoVCzKjGy9weT5Zg2H2fjmcz3GmG8GUCGZVdThYCAOPZtMqEzRbU/uDDax%2BWiEFQcV9gAKn5TeJWWWguTwG96DYQRuVHhRx/2CLtd11AFfcph0CxdILaMYgjyvO7W4ejvGFYZ4vcvoqzFD/OCvsbpTyoGlI0bY5ydiwLsP%2BEBB5EHmJZRacUBwB1HNtEALB76u1nuWRuZ5qI/BbneEEf8u6AMfP3OCqDUCC01LnFO7hfxXE1CPYwl8SATynmmGec9UyRiwukEw%2Bw5AoW%2BgQxidV6IfCoJBEEoR6KoAANYtUIq5OODMOKdU4fPa4x0YHVSLiXZ25dywXWdP7FKW48FsJBHIK4xNSZMDWJ1MBEAzDxGsIteI2YWSPmkRAo0ETvrDkDiwkAajNGuzwcLfaIIgHUEWDzIiR4F6RJPJXMxJ4XS0CUFExxb5WGOW/O4Vxx0SEL3Tj8UIXoTYMHzrWI0TjKnsM4czMoW1ylxJJtNTAnUR7l2ye02Jzifz10fGUPQMiyh5R4WPfhvi4q/gqe2eci4JlNxup0vSII8FghMI%2BKgLAoIxyWSsvhZxfH%2BL8TGFBQ9mHuzTGUC6pSYlJP4RcdZaEyTWXiO4BgFgDBdl3J8iZVY9mhULtQS5wY8FoCHvCEEW8LnEXJNUEpKLlhXPcBi8FwciJ%2BNBeCtKgEBnTPcImR8qAoiLKiMsi%2B491mpk2R%2BbZnZExwtltSW47gADSi5r72iiOYKwNgpldMOlwkAtyr41W5DrVsVAqBuFiJ/A5NK5UzJ9F4OZURNgyMZay3h7K/HWCCf6X0XYvk4O3Iav0UQYV5KpbGDgixaCcHiLwfwHAtCkFQJwIl0qrCymWKsZ4Ww9C8AIJob1iwdZP0GOWUgGiQCpk2HlRIqY9AaAAByphJBoDQPFEhcCSL6jgkheAsAkOW0ggbg2ho4LwBQIANCkETUG71pA4CwCQK6TAyBXlkAoCg4gwAFDKGMNUIQa9xSBp4KQNAN46AXEyPOpCS716tt4Bu5IdBBjohMJBBqDANHrvNie%2BgxBwgAM4Eeu9p7iAAHkh77pXUmwIqgx23BnV2jt/6x31HwIG3g/BBAiDEOwKQMhBCKBUOoftpBdDtCMCYFANgbCGBBl2pcIbHIgZZOqLMUqAmWD0MgfY5G3wSqzBKqjNheCEOIMQPAWAiMZqvU4NghVfS8cWAoaNax9B2DfKEXdi7l2roTR8dgPbxTMmSJwHgPq/UBr/e27AAHx3znNCWlkqZJBPmMMAa%2BYzr3BggOG6jnVcCEE7HG%2BYCak2V0zSATYqY8qSEkJsEkPEuCbD0DxHiGgAtFprZwetLbdMvrsN23tnmtMcHjQl9D7aPP9q8wrdILhJBAA%3D%3D
>>>>>>>>>>>
>>>>>>>>>>> Std-Discussion mailing list
>>>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Std-Discussion mailing list
>>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Brian Bi*
>>>>>>>>> Std-Discussion mailing list
>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Std-Discussion mailing list
>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Brian Bi*
>>>>>>> Std-Discussion mailing list
>>>>>>> Std-Discussion_at_[hidden]
>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>
>>>>>> --
>>>>>> Std-Discussion mailing list
>>>>>> Std-Discussion_at_[hidden]
>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Brian Bi*
>>>>>
>>>>
>>>
>>> --
>>> *Brian Bi*
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
>
> --
> *Brian Bi*
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
are missing every here and there. Aggregates can not use round bracket
constructors, the specialization doesn't need the generic variadic template
constructor(especially the `initializer_list`). Your `in_place`
constructors just need the simpler form. In case of RVO/NRVO, direct
initialization requires availability of move/copy constructor(even though
elided). Unfortunately I have difficulty accessing compiler explorer for a
variety of reasons. Finally, I don't understand the rationale behind
specializing standard library templates - which is ill-formed in general,
and for `optional` specifically. Finally, I recommend a reading of
"boost.tribool" docs. While `optional<bool>` doesn't seem to need
optimization IMHO. The baseline implementation would require two bytes, but
optimized builds may shorten it to 1. In either case, it doesn't seem to be
the bottle neck.
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 16 (Brian Bi)
>
>
>
> ---------- Forwarded message ----------
> From: Brian Bi <bbi5291_at_[hidden]>
> To: std-discussion_at_[hidden]
> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
> Bcc:
> Date: Wed, 17 Dec 2025 17:37:53 -0500
> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 16
>
>
> On Wed, Dec 17, 2025 at 5:31 PM Farid Mehrabi via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> You're missing a `bind`. You have to:
>>
>> 1. bind `ref(this->value)` to the input `f` to get a proper invocable. A
>> capturing lambda will do as well.
>>
>
> I skipped the `bind` by using nullary invocables in my example instead of
> unary ones (to simplify the example). I don't think it makes any difference
> to my point.
>
>
>>
>> 2. Next step is to wrap the bind/lambda in an emplacer object to get a
>> "convertible".
>>
>> 3. The convertible is then passed to proper constructor/emplace function.
>>
>
> You pass it to the desired constructor of `std::optional<U>`, but the
> important thing here is that you do not get to directly select which
> constructor of `U` gets used. The `in_place_t` constructor of
> `std::optional<U>` does overload resolution (using the arguments after the
> `in_place_t`) to select a constructor of `U`. In the normal course of
> things, the copy or move constructor of `U` gets selected, its parameter
> binds to the emplacer argument, and the copy/move constructor itself gets
> elided (see CWG2327/P2828 for an explanation). The example I showed
> demonstrates how it might be possible that a different constructor of `U`
> gets selected, and the emplacer doesn't end up getting used at all, even
> though you've passed it to `std::optional<U>`'s constructor.
>
> I've put in the work of showing a complete self-contained godbolt example
> to prove my point. If you can implement a function that takes an arbitrary
> callable (that returns `Immovable2` by value), and uses that callable to
> construct an `optional<Immovable2>`, please show a complete self-contained
> godbolt example.
>
>
>>
>> You keep moving the goal post. `transform` takes a unary invocable. It
>> doesn't have to do anything with variadic templates except for calling the
>> constructor with a single emplacer object. If the input invocable triggers
>> diagnostics, the user code is ill-formed. `immovable` can have as many
>> constructors as user demands. The one that is used in the lambda sent to
>> `transform` must be available in the context of definition of lambda:
>> ```cpp
>> optional<T> opt;
>> opt.transform
>> ( [](auto& v)
>> { return immobile{v, xxx};} );
>> ```
>> Wether or not `immobile{v, xxx}` is a valid expression, has nothing to do
>> with standard library definition. It's the responsibility of user code.
>>
>> As mentioned earlier, the input unary invocably must either return a
>> value, or a reference to copy/move constructible value; otherwise the user
>> code is ill-formed. That's the only requirement for `transform`.
>>
>> 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 12 (Brian Bi)
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Brian Bi <bbi5291_at_[hidden]>
>>> To: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>> Cc: std-discussion_at_[hidden]
>>> Bcc:
>>> Date: Wed, 17 Dec 2025 17:00:28 -0500
>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 12
>>>
>>>
>>> On Wed, Dec 17, 2025 at 4:24 PM Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>> wrote:
>>>
>>>> Here comes the implementation as well:
>>>> ```cpp
>>>> If (not this->has_value())
>>>> return nullopt;
>>>> /*define Local struct emplacer_t as before */
>>>> return optional<U>
>>>> { in_place, emplacer_t{ fn } };
>>>> ```
>>>> The `in_place_t` constructor template can be used to explicitly
>>>> initialize an instance of `optional`. No extra constructor is needed.
>>>>
>>>> You're original problem was to use an "invocable" as an input to a
>>>> public standard constructor. I gave you the emplacer idiom as the solution
>>>> to replace an "invocable" with a "convertible" in my initial answer,
>>>> assuming that you'd figure the proper constructor to apply the convertible.
>>>> In this post I demonstrated the proper constructor too. I hope you can
>>>> connect the dots at this point.
>>>>
>>>
>>> Okay, you want to make me do the work here. Fine.
>>>
>>> Here's a complete working example of how to use the emplacer idiom to
>>> construct an optional containing an immovable object, where that immovable
>>> object is initialized by calling a function that returns it by value:
>>>
>>> #include <functional>
>>> #include <optional>
>>>
>>> struct Immovable1 {
>>> Immovable1(int) {}
>>> Immovable1(const Immovable1&) = delete;
>>>
>>> static Immovable1 make() { return {1}; }
>>> };
>>>
>>> template <class F>
>>> struct Emplacer {
>>> F&& f;
>>> operator std::invoke_result_t<F>() const {
>>> return std::invoke((F&&)f);
>>> }
>>> };
>>>
>>> template <class F>
>>> std::optional<std::invoke_result_t<F>> makeOptional(F&& f) {
>>> return std::optional<std::invoke_result_t<F>>{std::in_place,
>>> Emplacer{(F&&)f}};
>>> }
>>>
>>> auto o1 = makeOptional(Immovable1::make);
>>>
>>> But let me show you a different value type for which this implementation
>>> doesn't work:
>>>
>>> struct Immovable2 {
>>> Immovable2(int) {}
>>> Immovable2(const Immovable2&) = delete;
>>>
>>> Immovable2(auto&&... args) {
>>> static_assert(sizeof...(args) > 100); // always false
>>> }
>>>
>>> static Immovable2 make() { return {1}; }
>>> };
>>>
>>> auto o2 = makeOptional(Immovable2::make); // triggers the static
>>> assertion
>>>
>>> The reason why this fails is that instead of using the emplacer's
>>> conversion function to initialize the `Immovable2` object, the `optional`
>>> constructor will instantiate and attempt to use the `Immovable2(auto&&...)`
>>> constructor (at which point the static assertion fires because there is
>>> only one argument, not more than 100). So, you see, if the type has a
>>> constructor like this, then the emplacer idiom doesn't work, because that
>>> constructor is "too good" in overload resolution.
>>>
>>> Here's the example on godbolt: https://godbolt.org/z/PzcK9rMah
>>>
>>> I think that I explained this very clearly in one of my previous
>>> messages: "If the type that needs to be constructed has an unconstrained
>>> constructor template, that constructor template will be used and the
>>> emplacer's conversion function will not be used."
>>>
>>>
>>>>
>>>>
>>>> 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!!!
>>>>
>>>> در تاریخ پنجشنبه ۱۸ دسامبر ۲۰۲۵، ۰۰:۲۸ Brian Bi <bbi5291_at_[hidden]>
>>>> نوشت:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 17, 2025 at 3:43 PM Farid Mehrabi via Std-Discussion <
>>>>> std-discussion_at_[hidden]> wrote:
>>>>>
>>>>>> Now you're skipping my response without enough proper attention and
>>>>>> focus.
>>>>>>
>>>>>
>>>>> I think you should take a step back and consider that you did not
>>>>> actually explain how to construct the `optional`. You explained the
>>>>> emplacer idiom, but you didn't show how to use it to implement `transform`.
>>>>> If I haven't understood you, it's because you haven't explained completely.
>>>>>
>>>>> I've actually implemented the monadic operations for `optional`, so I
>>>>> know how to use the emplacer idiom, so I've filled in the blanks in your
>>>>> email, and I've explained why the approach is not perfect. If you meant
>>>>> something different than what I meant, then you should show a working
>>>>> proof-of-concept implementation of `transform`.
>>>>>
>>>>>
>>>>>>
>>>>>> The emplacer object is constructed and explicitly converted by the
>>>>>> impelementation. The point of using emplacer idiom is to replace a function
>>>>>> call with a conversion, so the constructor/`emplace` member of result
>>>>>> object won't need an extra move construction. The result object
>>>>>> `optional<U>` has an explicit and fully specified type, so there will be no
>>>>>> mistakes:
>>>>>> ```cpp
>>>>>> template<typename T, typename F>
>>>>>> auto optioal<T>::transform(F&&)
>>>>>> -> optional<remove_cvref_t<invoke_result_t<F, T&>>>;
>>>>>> ```
>>>>>>
>>>>>
>>>>> How do you construct an `optional<U>` where `U` is immovable and the
>>>>> value of the contained `U` object is obtained by calling some function,
>>>>> call it `f`, that returns `U` by value? Which constructor of `optional<U>`
>>>>> do you call in order to do this?
>>>>>
>>>>> Do you do it like this?
>>>>>
>>>>> return optional<U>(emplacer{...});
>>>>>
>>>>> If so, you are calling constructor #9 shown on cppreference:
>>>>> https://en.cppreference.com/w/cpp/utility/optional/optional
>>>>>
>>>>> And I am telling you that this will not do the right thing if `U`
>>>>> happens to have a constructor like:
>>>>>
>>>>> template <class V>
>>>>> U(V&&);
>>>>>
>>>>>
>>>>>> Result type is already known, So there's only a simple
>>>>>> construction/emplace required for the result. Depending on implementation,
>>>>>> emplacer idiom may or may not be required. Anything `F` returns, will be
>>>>>> stripped off its qualifiers before converting into an `optional`. Compile
>>>>>> fails if proper copy/move constructors are unavailable. Now If your
>>>>>> argument is based on constraining standard library, that'll be a total
>>>>>> reboot not limited to a specific member function of a specific class.
>>>>>>
>>>>>> 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 10 (Brian Bi)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Brian Bi <bbi5291_at_[hidden]>
>>>>>>> To: std-discussion_at_[hidden]
>>>>>>> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>>>>>> Bcc:
>>>>>>> Date: Wed, 17 Dec 2025 15:11:46 -0500
>>>>>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue 10
>>>>>>> What you're calling `U` is what I called `T` in my example (the type
>>>>>>> that needs to be constructed).
>>>>>>>
>>>>>>> If the type that needs to be constructed has an unconstrained
>>>>>>> constructor template, that constructor template will be used and the
>>>>>>> emplacer's conversion function will not be used. That is the problem.
>>>>>>>
>>>>>>> On Wed, Dec 17, 2025 at 3:09 PM Farid Mehrabi via Std-Discussion <
>>>>>>> std-discussion_at_[hidden]> wrote:
>>>>>>>
>>>>>>>> I guess you're missinterpreting the usage of `transform`. The
>>>>>>>> output type `U` is deduced from `invoke_result_t<F>`. It has nothing to do
>>>>>>>> with original `T`. If the `F` instance doesn't mutate the original `T`
>>>>>>>> instance, it won't be modified. `T` and `U` don't need to have any
>>>>>>>> relation; the requirment is `invocable<F(T&)>`(`T` reference gets same
>>>>>>>> qualifiers as `this`), and `U` is deduced to `auto{f(t)}`.
>>>>>>>>
>>>>>>>> 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 (Brian Bi)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Brian Bi <bbi5291_at_[hidden]>
>>>>>>>>> To: std-discussion_at_[hidden]
>>>>>>>>> Cc: Farid Mehrabi <farid.mehrabi_at_[hidden]>
>>>>>>>>> Bcc:
>>>>>>>>> Date: Wed, 17 Dec 2025 14:17:57 -0500
>>>>>>>>> Subject: Re: [std-discussion] Std-Discussion Digest, Vol 81, Issue
>>>>>>>>> 8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Dec 16, 2025 at 10:28 AM Farid Mehrabi via Std-Discussion <
>>>>>>>>> std-discussion_at_[hidden]> wrote:
>>>>>>>>>
>>>>>>>>>> There's a very unpopular idiom about this. I call it the
>>>>>>>>>> **emplacer** idiom, which can be used in many different scenarios where the
>>>>>>>>>> proper constructor is not available. It relies on the C++20 mandated direct
>>>>>>>>>> initialization on returned objects:
>>>>>>>>>> ```cpp
>>>>>>>>>> template<invocable<> F>
>>>>>>>>>> struct implacer_t{
>>>>>>>>>> F&& fn;
>>>>>>>>>> operator auto() const
>>>>>>>>>> { return invoke(forward<F>(fn)); };
>>>>>>>>>> }; // ! emplacer
>>>>>>>>>> ```
>>>>>>>>>> The `emplacer_t` class converts any references to invocable
>>>>>>>>>> objects into conversion to returned object, and can be fed to `emplace`
>>>>>>>>>> members of any standard class. It can also be used to call private
>>>>>>>>>> constructors of classes while using `make_unique` or `make_shared`. Usage
>>>>>>>>>> is as simple as:
>>>>>>>>>> ```cpp
>>>>>>>>>> auto fn = []<typname ...A>(A&&...v)
>>>>>>>>>> { return T{forward<A>(v)}; };
>>>>>>>>>>
>>>>>>>>>> my_obj.emplace
>>>>>>>>>> ( emplacer_t
>>>>>>>>>> { bind(fn,args...) } );
>>>>>>>>>> ```
>>>>>>>>>> I just think that the emplacer idiom requires standard
>>>>>>>>>> exposition. A few convenience CPO should be added, that make the idiom
>>>>>>>>>> publicly available to standard library users:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am sure that the standard library implementors know this trick.
>>>>>>>>> The problem is that it doesn't actually let you implement the spec
>>>>>>>>> perfectly. Consider the case of an `optional<T>` where `T` has a
>>>>>>>>> constructor like this:
>>>>>>>>>
>>>>>>>>> template <class U>
>>>>>>>>> T(U&&);
>>>>>>>>>
>>>>>>>>> In other words, there is an implicit conversion from any type to
>>>>>>>>> `T`. Now, if you attempt to construct a `T` using what you've called the
>>>>>>>>> emplacer idiom, this constructor will be called, since it will win overload
>>>>>>>>> resolution compared with the alternative of calling the move constructor of
>>>>>>>>> `T` (with the T&& binding to the T returned by the emplacer's conversion
>>>>>>>>> function).
>>>>>>>>>
>>>>>>>>> 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 Rasheeg points out, and LWG should
>>>>>>>>> decide what to do about it, e.g.:
>>>>>>>>>
>>>>>>>>> - ban user-defined specializations of `optional`?
>>>>>>>>> - recommend to LEWG that they add the necessary constructor to
>>>>>>>>> the public interface?
>>>>>>>>> - modify the spec so that it explicitly uses the emplacer
>>>>>>>>> idiom (thus not requiring support for cases where the emplacer idiom
>>>>>>>>> doesn't work)?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> - `default_emplacer` a CPO that can convert to any object with
>>>>>>>>>> public default constructor via calling the constructor.
>>>>>>>>>> - `emplace_args` embeds a forwarding tuple and returns an object
>>>>>>>>>> constructed from tuple elements upon conversion.
>>>>>>>>>> - `emplace_result` the most generic case that wraps the
>>>>>>>>>> `emplacer_t` class and returns an instance.
>>>>>>>>>> These 3 CPO can help in various situations of emplacement in user
>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> FM.
>>>>>>>>>>
>>>>>>>>>> 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. Implementing std::optional<T>::transform (Rasheeq Azad)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>> From: Rasheeq Azad <rasheeqhere_at_[hidden]>
>>>>>>>>>>> To: Std-Discussion_at_[hidden]
>>>>>>>>>>> Cc:
>>>>>>>>>>> Bcc:
>>>>>>>>>>> Date: Sun, 14 Dec 2025 16:00:00 -0500
>>>>>>>>>>> Subject: [std-discussion] Implementing
>>>>>>>>>>> std::optional<T>::transform
>>>>>>>>>>> In the current draft, [optional.monadic] specifies that
>>>>>>>>>>> std::optional<T>::transform(F &&f) & shall do the following:
>>>>>>>>>>>
>>>>>>>>>>> > Let U be remove_cv_t<invoke_result_t<F, decltype(*val)>>.
>>>>>>>>>>> > Mandates: ...
>>>>>>>>>>> > [Note 1: There is no requirement that U is movable
>>>>>>>>>>> ([dcl.init.general]).
>>>>>>>>>>> > Returns: If *this contains a value, an optional<U> object
>>>>>>>>>>> whose contained value is direct-non-list-initialized with
>>>>>>>>>>> invoke(std::forward<F>(f), *val); otherwise, optional<U>().
>>>>>>>>>>>
>>>>>>>>>>> I'm wondering how this is supposed to be implemented. None of the
>>>>>>>>>>> standard constructors of std::optional<U> directly support
>>>>>>>>>>> initializing the contained object with an invocable. Both GCC
>>>>>>>>>>> libstdc++ [1a] [1b] [1c] and LLVM libc++ [2a] [2b] [2c] get
>>>>>>>>>>> around
>>>>>>>>>>> this by adding an internal-use-only (using a tag type that has a
>>>>>>>>>>> reserved name) constructor to std::optional<T> that takes the
>>>>>>>>>>> invocable and calls it to initialize the contained object. But
>>>>>>>>>>> this
>>>>>>>>>>> means that std::optional<T> relies on the *different
>>>>>>>>>>> specialization*
>>>>>>>>>>> std::optional<U> supporting this nonstandard constructor.
>>>>>>>>>>>
>>>>>>>>>>> As a consequence, neither library can fully cope with me
>>>>>>>>>>> defining my
>>>>>>>>>>> own specialization of std::optional. I hoped this was just an
>>>>>>>>>>> implementation bug and filed an issue with LLVM about it, [3],
>>>>>>>>>>> which
>>>>>>>>>>> contains a code example and my proposed solution (see also on
>>>>>>>>>>> [Godbolt]), but someone else pointed out that my proposed
>>>>>>>>>>> solution
>>>>>>>>>>> also has an edge case. So as far as I can tell right now, it
>>>>>>>>>>> seems
>>>>>>>>>>> impossible to implement std::optional<T>::transform while using
>>>>>>>>>>> only
>>>>>>>>>>> the standard interface of the other specialization
>>>>>>>>>>> std::optional<U>.
>>>>>>>>>>>
>>>>>>>>>>> If this really is the case, then the standard seems to have
>>>>>>>>>>> inadvertently prohibited program-defined specializations of
>>>>>>>>>>> std::optional with the addition of std::optional<T>::transform.
>>>>>>>>>>> I'm
>>>>>>>>>>> hoping to get more eyes on this question. If someone in this list
>>>>>>>>>>> could come up with a way to implement
>>>>>>>>>>> std::optional<T>::transform in a
>>>>>>>>>>> way that permits program-defined specializations (or say with
>>>>>>>>>>> more
>>>>>>>>>>> certainty that it's in fact not possible), that'd be great. Have
>>>>>>>>>>> I
>>>>>>>>>>> found a standard defect?
>>>>>>>>>>>
>>>>>>>>>>> - Rasheeq Azad
>>>>>>>>>>>
>>>>>>>>>>> [1a]:
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L97
>>>>>>>>>>> [1b
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L97[1b>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1490-L1493
>>>>>>>>>>> [1c
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1490-L1493[1c>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1391
>>>>>>>>>>> [2a
>>>>>>>>>>> <https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/libstdc%2B%2B-v3/include/std/optional#L1391[2a>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L369
>>>>>>>>>>> [2b
>>>>>>>>>>> <https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L369[2b>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L925-L927
>>>>>>>>>>> [2c
>>>>>>>>>>> <https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L925-L927[2c>]:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/llvm/llvm-project/blob/9975cb166ea3925738abb8d0db0028e418315eda/libcxx/include/optional#L1144
>>>>>>>>>>> [3]: https://github.com/llvm/llvm-project/issues/172197
>>>>>>>>>>> [Godbolt]:
>>>>>>>>>>> https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYgATKVpMGoZAFI9AIQuXSS%2BsgJ4BlRugDCqWgFcWDCaRuADJ4DJgAcr4ARpjEIACs8aQADqgKhM4Mnj5%2BAanpTgIhYZEsMXGJdpgOhQxCBEzEBNm%2B/lxVNZn1jQTFEdGxCUkKDU0tue0jPX2l5UMAlHao3sTI7BwWAMyhyD5YANRmm%2B78xCxMBEfYZhoAgls7e5iHx84jxJisVzf3etsMu28ByO7neoWA3zuPweAKeL08yVqYkh9zuuyYCgU%2BxYAE8APpRVBeQ4Adks%2BwA9BT9kx9sliKhgMRWABaLA0MLofYEHHJZ4ASWxeGACAI%2BwA7sYxUR9go%2Bcg8GI8AAvZ4jdAgECoRGZMT7U4/fb7ZAIRr7VRHax3ZLeKK0PDIECG/aYVTJe0KsW4glE2gQQnE1TzfYgc0QIOk8lmEkAEWd3oDfoTvosADY08GjjH9lh6ARMJbnQA/ZNeCCZsmkuObK2o25G13uh2Efba2IXEj7RPl40CEaR/YfAgrBjmy1V%2BP4xOtvnMojEMCQYNoBj96Pkocj7FT30QRfdoPzcfRuNQ2OFqF3fMsd0XAvHK7GoyY2UEDVanUCZHHUu0R/r513m8RwaSiJRBDxMV12NU1iFlRgnDCWgXmzPRj3PGtnW8BhMgHX86Q%2BcDLhrUCiMg0iEPQ6tySpWUmAAN0wLlaSiHF80OAAxDQzAATg4sxbniMxLE2RcfhtO0HSdO4jVoj56HoqVsUwMpYgUZ0VxGRs4O1JE/WDBhUFdNZERDCjBB7aCTw0vt8zdHTP2YP0GG8WhaF0yCDKM1QTLFUNdN1fSB2smSZz0iAAq/ZDNMuPRU0zTZs1zTB8wvOsjWvW9UuOdEXwAOgKgAVR8PgAR28PBCP2PAFDxGLiGApw7UwPF6JBX9SH2QqCrylEjRi7SXTdD0W0ipyIFCPFbzWSDOsKw44rTHqCGDUN6UwIiIHVTVTklYh0BBYrNmwCAVp6iso3PS9625FSsvvdxcqxIJOqe/YeqO7BB0wcrKo26ravqxq8Ga1r2p3LxOtCDIlVVYg8XtEYQSCb44rmnq%2Bt7Vc7PpIam09MLAomhgpqMGaCChnCnFh2IEZq4j3BR479loOaFvTOLltWgiNoQiBWdfd9dsaA7jk%2B075nO4Krpu2iV0YppwSxoDHBILFjC5VACAQWJ9mAEgcRzFKmDoLFUBYQh8wO67%2Btswbp1NWrFJ8TAexi/ZDOMzBTIA0KjU3YhRyYMCELyojQmqfYxMS8yCEg8sw4QiO/0w0KQpugb7P2IsxrESzKzwKgIEd1qxG8V35mDdaiLyksIf0qjoVCzKjGy9weT5Zg2H2fjmcz3GmG8GUCGZVdThYCAOPZtMqEzRbU/uDDax%2BWiEFQcV9gAKn5TeJWWWguTwG96DYQRuVHhRx/2CLtd11AFfcph0CxdILaMYgjyvO7W4ejvGFYZ4vcvoqzFD/OCvsbpTyoGlI0bY5ydiwLsP%2BEBB5EHmJZRacUBwB1HNtEALB76u1nuWRuZ5qI/BbneEEf8u6AMfP3OCqDUCC01LnFO7hfxXE1CPYwl8SATynmmGec9UyRiwukEw%2Bw5AoW%2BgQxidV6IfCoJBEEoR6KoAANYtUIq5OODMOKdU4fPa4x0YHVSLiXZ25dywXWdP7FKW48FsJBHIK4xNSZMDWJ1MBEAzDxGsIteI2YWSPmkRAo0ETvrDkDiwkAajNGuzwcLfaIIgHUEWDzIiR4F6RJPJXMxJ4XS0CUFExxb5WGOW/O4Vxx0SEL3Tj8UIXoTYMHzrWI0TjKnsM4czMoW1ylxJJtNTAnUR7l2ye02Jzifz10fGUPQMiyh5R4WPfhvi4q/gqe2eci4JlNxup0vSII8FghMI%2BKgLAoIxyWSsvhZxfH%2BL8TGFBQ9mHuzTGUC6pSYlJP4RcdZaEyTWXiO4BgFgDBdl3J8iZVY9mhULtQS5wY8FoCHvCEEW8LnEXJNUEpKLlhXPcBi8FwciJ%2BNBeCtKgEBnTPcImR8qAoiLKiMsi%2B491mpk2R%2BbZnZExwtltSW47gADSi5r72iiOYKwNgpldMOlwkAtyr41W5DrVsVAqBuFiJ/A5NK5UzJ9F4OZURNgyMZay3h7K/HWCCf6X0XYvk4O3Iav0UQYV5KpbGDgixaCcHiLwfwHAtCkFQJwIl0qrCymWKsZ4Ww9C8AIJob1iwdZP0GOWUgGiQCpk2HlRIqY9AaAAByphJBoDQPFEhcCSL6jgkheAsAkOW0ggbg2ho4LwBQIANCkETUG71pA4CwCQK6TAyBXlkAoCg4gwAFDKGMNUIQa9xSBp4KQNAN46AXEyPOpCS716tt4Bu5IdBBjohMJBBqDANHrvNie%2BgxBwgAM4Eeu9p7iAAHkh77pXUmwIqgx23BnV2jt/6x31HwIG3g/BBAiDEOwKQMhBCKBUOoftpBdDtCMCYFANgbCGBBl2pcIbHIgZZOqLMUqAmWD0MgfY5G3wSqzBKqjNheCEOIMQPAWAiMZqvU4NghVfS8cWAoaNax9B2DfKEXdi7l2roTR8dgPbxTMmSJwHgPq/UBr/e27AAHx3znNCWlkqZJBPmMMAa%2BYzr3BggOG6jnVcCEE7HG%2BYCak2V0zSATYqY8qSEkJsEkPEuCbD0DxHiGgAtFprZwetLbdMvrsN23tnmtMcHjQl9D7aPP9q8wrdILhJBAA%3D%3D
>>>>>>>>>>>
>>>>>>>>>>> Std-Discussion mailing list
>>>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Std-Discussion mailing list
>>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Brian Bi*
>>>>>>>>> Std-Discussion mailing list
>>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Std-Discussion mailing list
>>>>>>>> Std-Discussion_at_[hidden]
>>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Brian Bi*
>>>>>>> Std-Discussion mailing list
>>>>>>> Std-Discussion_at_[hidden]
>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>>
>>>>>> --
>>>>>> Std-Discussion mailing list
>>>>>> Std-Discussion_at_[hidden]
>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Brian Bi*
>>>>>
>>>>
>>>
>>> --
>>> *Brian Bi*
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
>
> --
> *Brian Bi*
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Received on 2025-12-18 00:26:58