I think you can do it today by 'misusing' the copy operations and implementing them as move for those classes.   -----Ursprüngliche Nachricht----- Von:Михаил Найденов via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 19.05.2023 10:44 Betreff:[std-proposals] Question regarding move-only objects improvements An:sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>; CC:Михаил Найденов <mihailnajdenov_at_[hidden]>; 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   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals