Date: Wed, 7 Dec 2022 22:01:22 +0800
On Wed, 7 Dec 2022 at 20:27, Bo Persson via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On 2022-12-07 at 13:09, Yongwei Wu via Std-Discussion wrote:
> > Thanks for the response.
> >
> > Right, it seems there is no harm in forwarding. But my question is in
> > the other direction: What possible harm could there be in real
> > scenarios, if there were no special treatment for the const rvalue?
>
> In general, a const lvalue reference allows a conversion to a type that
> can bind to the reference. Perhaps we want to avoid that?
Yup, that is the purpose of `=delete` for const T&& in some templates
:-). But still, I was talking about the cases of std::get, where the
const T&& overload is not deleted.
The background is that some people in the team are arguing that we
should forbid std::move on const objects. That basically also forbids
implementing something like get(const tuple<Types...>&& t). I am
looking for whether there are any valid cases of using this kinds of
overloads.
<std-discussion_at_[hidden]> wrote:
>
> On 2022-12-07 at 13:09, Yongwei Wu via Std-Discussion wrote:
> > Thanks for the response.
> >
> > Right, it seems there is no harm in forwarding. But my question is in
> > the other direction: What possible harm could there be in real
> > scenarios, if there were no special treatment for the const rvalue?
>
> In general, a const lvalue reference allows a conversion to a type that
> can bind to the reference. Perhaps we want to avoid that?
Yup, that is the purpose of `=delete` for const T&& in some templates
:-). But still, I was talking about the cases of std::get, where the
const T&& overload is not deleted.
The background is that some people in the team are arguing that we
should forbid std::move on const objects. That basically also forbids
implementing something like get(const tuple<Types...>&& t). I am
looking for whether there are any valid cases of using this kinds of
overloads.
Received on 2022-12-07 14:01:35