Hi,

optional<T> assignment has the semantics of "initialize or assign", and indeed, typically there is no observable difference (hello, pmr::vector). The problem with reference types is that the difference in semantics is painfully obvious there. You seem to biased that "always initialize" makes sense here. I say that we have optional::emplace() for that.

-Lénárd


-------- Original Message --------
From: Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>
Sent: August 2, 2021 11:26:10 AM GMT+01:00
To: std-proposals_at_[hidden]
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
Subject: Re: [std-proposals] Yet another member function for std::map

On 8/2/21 12:28 PM, Lénárd Szolnoki via Std-Proposals wrote:
>
> The Achilles' heel of optional<T&> seems to be assignment. I'm of the
> opinion that it simply shouldn't have assignment from arguments of type
> T, but I believe there is no perfect answer.

Personally, I have no problem with rebinding semantics of
optional<T&>::operator=(T&). That it would affect the referred object
makes no sense because (a) there may not be such an object (if the
optional is empty) and (b) no other version of optional<T> acts this
way. In order to access the referred object one has to use operator* or
operator-> or similar accessors, and assignment is no exception.

Having the assignment is important to be able to initialize an empty
optional. Yes, you could assign from a temporary optional, but that is
unnecessarily verbose, IMHO. In any case, this is not the reason to not
have optional<T&> at all.

-- 
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals