In general, if I need an rvalue and it's legal to convert the lvalue I have into an rvalue, the compiler should do it automatically. Having to make it explicit should be the exception, not the rule. The compiler does many other kinds of inference and automatic promotion/conversion, some of them far more difficult (and dangerous). Why not this one?
How do you even tell that it's legal to stick std::move around a variable? Here's a really simple example.
void test() {
std::string s = ...;
foo(s);
bar(s);
}
Can I change the last line to bar(std::move(s))? I can write a well-formed program that will misbehave, perhaps something like
(Note that s.data() is not necessarily unchanged after std::move'ing the object, due to small-string optimization.)
This is contrived, but my point is that this is really tricky to do automatically.
Note also that when adding rvalue references the language committee had the additional constraint of not breaking existing programs. This makes things like automatic inference of temporariness even trickier.
The compiler does many other kinds of inference and automatic promotion/conversion, some of them far more difficult (and dangerous).
The C++ compiler does exceptionally few transformations that can change the behavior of a well-formed program. In fact, the only one that comes to mind is copy elision (aka RVO).
> The C++ compiler does exceptionally few transformations that can change the behavior of a well-formed program.
So all of those conversions between numeric, pointer, or string-ish types are just figments of my imagination? The rules for which constructor to use, which template or overload to apply, aren't a form of inference? "Auto" doesn't exist? Maybe there's some class of transformations and some definition of "well formed" for which your statement is true, but I can't imagine what those are.
Those are all things you asked to have. The topic was things you coded, but that the compiler did not generate code to do.
To be precise: by the object model, a constructor and destructor were supposed to be called. The compiler, by special dispensation, avoided calling them.
You may complain that the object model is whatever the standard says the compiler must do, in which case the statement would be vacuous: no transformations.
How do you even tell that it's legal to stick std::move around a variable? Here's a really simple example.
void test() { std::string s = ...; foo(s); bar(s); }
Can I change the last line to bar(std::move(s))? I can write a well-formed program that will misbehave, perhaps something like
char* global; void foo(const std::string& s) { global = s.data(); }
void bar(const std::string& s) { assert(global == s.data()); }
(Note that s.data() is not necessarily unchanged after std::move'ing the object, due to small-string optimization.)
This is contrived, but my point is that this is really tricky to do automatically.
Note also that when adding rvalue references the language committee had the additional constraint of not breaking existing programs. This makes things like automatic inference of temporariness even trickier.
The compiler does many other kinds of inference and automatic promotion/conversion, some of them far more difficult (and dangerous).
The C++ compiler does exceptionally few transformations that can change the behavior of a well-formed program. In fact, the only one that comes to mind is copy elision (aka RVO).