On 07/12/2022 15.01, Yongwei Wu via Std-Discussion wrote:
> 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.


Disallowing std::move on const objects seems problematic for generic code

Why not use something else, like fmove (shorthand for force-move) to be
sure that moving is a no-op/a simple copy?

https://fekir.info/post/fmove/


Federico