On 2023-05-19 at 10:43, Михаил Найденов via Std-Proposals wrote:
> Hello, what the arguments would be against making move-only objects move
> w/o std::move? In other words, what is a compilation error today - to
> assign a move-only object to another instance, or pass into a function,
> expecting rvalue ref or a copy - will perform a move instead silently.
>
> One such downside is that it will be less clear, the object is "shell"
> after said operation, but this is not that problematic IMO - the
> behaviour is "documented" inside the type (it's a move-only class,
> passing it around moves its guts) also tools can help.
>
> The benefit of such a change is that it would become possible to write a
> library, where the move is the default (all objects are either cheap to
> copy or move-only, with explicit clone/copy function/specialization) and
> the user will use said library w/ guaranteed performance (no incidental
> copies) and no syntax fluff (unless copy is needed).
>

We used to have auto_ptr that moved in its copy constructor and
assignment. Terribly confusing!

You would have to consider "guaranteed performance" against code like

a = b;
a = b;

having now lost the object!