Date: Fri, 19 May 2023 11:43:49 +0300
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).
Thank You
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).
Thank You
Received on 2023-05-19 08:44:02