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@lists.isocpp.org> wrote:


On Mon, Nov 20, 2023 at 1:11 PM Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Be seeing you,
Tony