On 31/01/2022 15.21, Giuseppe D'Angelo via Std-Proposals wrote:
> Hi,
>
> On 31/01/2022 14:04, Avi Kivity via Std-Proposals wrote:
>> std::move() silently falls back to copying if it cannot move. This can
>> cause unexpected slowdown which is expensive to pinpoint.
>>
>>
>> I propose std::must_move(), with deleted overloads for const T& and
>> const T&&. This allows the user to request a diagnostic instead of
>> falling back to a copy.
>>
>
> I'm not too fond of introducing yet another vocabulary verb for moving
> (... tu quoque...), when this can be solved via static analysis instead:
>
>> https://clang.llvm.org/extra/clang-tidy/checks/performance-move-const-arg.html
>>
>
>
> My 2 c,
>

That's fair. Personally I don't like these solutions, since they're like
warnings. If you have cases you can't fix (say in templates) you need to
continuously ignore the warnings for the expected places, or disable the
warning if you can't handle the flood.


Perhaps std::move() in such an ambiguous situation is rare enough not to
care about.