Date: Wed, 22 Nov 2023 10:03:18 -0500
I have implemented it.
It just isn't used that much. So no real implementation experience either
way. It hasn't been a problem, but neither optional<T&> nor assignment
come up that much at all, so inconclusive.
If anything, I'd say
Imagine that vector.front() returns an optional<T&>...
As the developer writing vector, I'd like assignment to rebind.
As the developer using vector.front(), I'd like assignment to not rebind.
auto f = vector.front();
if (f)
f = 17; // current optional would not be able to assign from an rvalue
But again, totally inconclusive.
The underlying problem is references, not optional, but I'm not going to
argue it.
On Mon, Nov 20, 2023 at 1:25 PM JeanHeyd Meneide via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Mon, Nov 20, 2023 at 1:11 PM Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I heard couple problems with the design of this optional,
>> as there are two competing approaches to how it should work.
>> Question is why then does the standard avoid some of this problems
>> and have for example `optional_ref<T>`?
>>
>
> What you heard of is a fantasy scenario, cooked up by people who
> never implemented the optional they talked about. They spent so much time
> pontificating about it rather than trying it out and seeing the obvious
> flaws in its design that they rolled back clearly deployed, widely
> implemented, and heavily used existing practice for the standard version of
> std::optional. optional_ref<T> is a solution looking for a problem that
> never existed both in its theory beyond shallow FUD examples, and in its
> practice since it was literally never implemented.
>
> Ever.
>
> Paper: https://thephd.dev/_vendor/future_cxx/papers/d1683.html
> Blog: https://thephd.dev/to-bind-and-loose-a-reference-optional
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
It just isn't used that much. So no real implementation experience either
way. It hasn't been a problem, but neither optional<T&> nor assignment
come up that much at all, so inconclusive.
If anything, I'd say
Imagine that vector.front() returns an optional<T&>...
As the developer writing vector, I'd like assignment to rebind.
As the developer using vector.front(), I'd like assignment to not rebind.
auto f = vector.front();
if (f)
f = 17; // current optional would not be able to assign from an rvalue
But again, totally inconclusive.
The underlying problem is references, not optional, but I'm not going to
argue it.
On Mon, Nov 20, 2023 at 1:25 PM JeanHeyd Meneide via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Mon, Nov 20, 2023 at 1:11 PM Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I heard couple problems with the design of this optional,
>> as there are two competing approaches to how it should work.
>> Question is why then does the standard avoid some of this problems
>> and have for example `optional_ref<T>`?
>>
>
> What you heard of is a fantasy scenario, cooked up by people who
> never implemented the optional they talked about. They spent so much time
> pontificating about it rather than trying it out and seeing the obvious
> flaws in its design that they rolled back clearly deployed, widely
> implemented, and heavily used existing practice for the standard version of
> std::optional. optional_ref<T> is a solution looking for a problem that
> never existed both in its theory beyond shallow FUD examples, and in its
> practice since it was literally never implemented.
>
> Ever.
>
> Paper: https://thephd.dev/_vendor/future_cxx/papers/d1683.html
> Blog: https://thephd.dev/to-bind-and-loose-a-reference-optional
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- Be seeing you, Tony
Received on 2023-11-22 15:03:33