Date: Mon, 02 Aug 2021 18:55:09 +0000
On Monday, August 2nd, 2021 at 7:59 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I think that's the core of the problem here: the "right semantic" for
> references is not the "right semantic" for values. It makes
> absolutely no sense for assignment to an optional value type to
> unengage/re-engage. Values are values, and if a value is assignable,
> then assigning to it has a clear and unambiguous meaning.
>
When we talk about "semantics," we
should consider the semantics of the
entire type. The behaviors of specific
methods are only behaviors. They are
granted a name, a concept, only when
all the methods of a type make sense
at the same time.
I gave a talk last year on reference_wrapper,
https://youtu.be/EKJMZCL00Ak?t=239
pointed out that reference_wrapper
models "rebindable reference," while
T& is not rebindable. Now the question
is, will optional<T&> rebindable? It
is, given both of the designs discussed
in this thread. It is also rebindable
in
http://wg21.link/p1175r0
It is rebindable unless it has no
operator= at all, like what
https://www.foonathan.net/2018/07/optional-reference/
shows. Because T& is "immutable,"
a "T* const" with a different syntax.
Pedantically speaking, optional<T&>
supposes to be similar to
optional<int const>.
But given the same logic, we could
have a reference_wrapper that is not
rebindable either. Recall that a
major part of its use is to revert
the decay-copy behavior in argument
passing, where you don't need
reference rebinding.
> `vector`'s are supposed to have specific behavior, and `vector<bool>`
> doesn't follow that. Same goes for `optional<T>`: it has specific,
> reasonable behavior which `optional<T&>` wouldn't have.
>
> If you believe that this is the right semantic for references, then it
> needs to be a separate class from optional values.
My suggestion is to make optional<T&>
fully rebindable. What "optional" does
here is to make T& mutable in addition
to nullable. To me, this is similar to
unique_ptr<T[]> which makes T[] a
complete type.
>
> I think that's the core of the problem here: the "right semantic" for
> references is not the "right semantic" for values. It makes
> absolutely no sense for assignment to an optional value type to
> unengage/re-engage. Values are values, and if a value is assignable,
> then assigning to it has a clear and unambiguous meaning.
>
When we talk about "semantics," we
should consider the semantics of the
entire type. The behaviors of specific
methods are only behaviors. They are
granted a name, a concept, only when
all the methods of a type make sense
at the same time.
I gave a talk last year on reference_wrapper,
https://youtu.be/EKJMZCL00Ak?t=239
pointed out that reference_wrapper
models "rebindable reference," while
T& is not rebindable. Now the question
is, will optional<T&> rebindable? It
is, given both of the designs discussed
in this thread. It is also rebindable
in
http://wg21.link/p1175r0
It is rebindable unless it has no
operator= at all, like what
https://www.foonathan.net/2018/07/optional-reference/
shows. Because T& is "immutable,"
a "T* const" with a different syntax.
Pedantically speaking, optional<T&>
supposes to be similar to
optional<int const>.
But given the same logic, we could
have a reference_wrapper that is not
rebindable either. Recall that a
major part of its use is to revert
the decay-copy behavior in argument
passing, where you don't need
reference rebinding.
> `vector`'s are supposed to have specific behavior, and `vector<bool>`
> doesn't follow that. Same goes for `optional<T>`: it has specific,
> reasonable behavior which `optional<T&>` wouldn't have.
>
> If you believe that this is the right semantic for references, then it
> needs to be a separate class from optional values.
My suggestion is to make optional<T&>
fully rebindable. What "optional" does
here is to make T& mutable in addition
to nullable. To me, this is similar to
unique_ptr<T[]> which makes T[] a
complete type.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2021-08-02 13:55:18