Date: Fri, 7 Feb 2020 14:04:21 +0200
On Fri, 7 Feb 2020 at 12:31, Corentin <corentin.jabot_at_[hidden]> wrote:
> The point I was trying to make was that the necessity of not having
> operator=() in optional<T&>
> comes from the need to course correct for the presence of that
> assignment operator which should not have been there to begin with,
> not because of a fundamental semantic difference between optional<T&>
> and optional<T>
I'm not sure I follow this either. We made the design more complex
when we added converting
assignments, and the whole when-to-unpack-when-not is far from simple,
but I utterly fail to see
what was ever wrong with being able to assign an optional<T> from a T,
and what makes that
operation something that "shouldn't have been there to begin with".
> The point I was trying to make was that the necessity of not having
> operator=() in optional<T&>
> comes from the need to course correct for the presence of that
> assignment operator which should not have been there to begin with,
> not because of a fundamental semantic difference between optional<T&>
> and optional<T>
I'm not sure I follow this either. We made the design more complex
when we added converting
assignments, and the whole when-to-unpack-when-not is far from simple,
but I utterly fail to see
what was ever wrong with being able to assign an optional<T> from a T,
and what makes that
operation something that "shouldn't have been there to begin with".
Received on 2020-02-07 06:07:10