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@lists.isocpp.org>
Gesendet: Fr 19.05.2023 10:44
Betreff: [std-proposals] Question regarding move-only objects improvements
An: sotrdg sotrdg via Std-Proposals <std-proposals@lists.isocpp.org>;
CC: Михаил Найденов <mihailnajdenov@gmail.com>;

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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals