I would be curious about the rationale behind this. Move semantics are a clear win in many situations, and I don't see any obvious pitfalls associated with them. I am curious especially about mere std::move; I'm aware that using rvalue references directly can be a bit confusing initially, and it makes sense to reduce their use.
Last I heard the C++ style arbiters at Google (a handful of very-senior engineers who dictate how everyone else at the company should write code) felt that rvalue references were too hard to understand and would therefore lead to more problems than they solve.
Admittedly my knowledge is a couple years old, but the rule specified here of "you can only use them with explicit permission from the C++ style arbiters; maybe we'll reconsider later" seems consistent with that reasoning.
I'm glad I don't follow their rules anymore. rvalue references are incredibly useful in making ownership transfers explicit, and although they may sound confusing on first description, once you get the hang of it, they are easy to reason about.
The problem is you're demanding that the entire coding population of a large company "get the hang of it" or else be confused by their tools. That is a proposition with non-zero cost, so it needs to be weight against the derived benefit.
And IMHO for move semantics, that benefit is pretty low. The overwhelming number of allocation bugs with C++ code are treated very well by RAII already. Move semantics tend to be best used in library code that implements some kind of dynamic runtime. And let's be honest: that's stuff that (1) tends to be done by experts already and (2) has been done successfully and robustly for decades in C anyway. Larry and Guido didn't need move semantics...
> The problem is you're demanding that the entire coding population of a large company "get the hang of it" or else be confused by their tools.
The fact of life in C++ is that you have to grasp a number of not-entirely-intuitive concepts before you can be effective with it. Rvalue references are not particularly hard compared to many of the others. Consider how much time newbies spend wrapping their head around pointers -- something that experienced C++ programmers have absolutely no trouble with.
The only reason we're holding rvalue references to a higher standard than any other C++ feature is because they're new, which means that even people who have been coding in C++ for decades suddenly find that there is a language construct they don't immediately understand. Not having felt this way for a very long time, they conclude that this particular construct must be much more complicated than everything else, when in fact it's not.
> The overwhelming number of allocation bugs with C++ code are treated very well by RAII already.
Move semantics make it vastly easier to use RAII in the first place. Without them, RAII does not play nicely with transferring ownership over a call or a return. You can use reference-counted smart pointers, but they are slow (require atomic ops). You can try to emulate move semantics via documentation and conventions, but this is error-prone. Clean ownership transfers have always been a sore spot in C++ prior to rvalue references.
I don't know about you, but the introduction of move semantics into my style completely transformed my code for the better.
We don't allow the standard version yet partly for the reason explained downthread: it requires stl support to be very useful and not all the platforms we target are compatible yet.
Its more than that. You can't put move-only types into std:: containers if the target doesn't have a C++11 support. There are many other pitfalls like this that are hard to notice until you try it on a pre-C++11 target.
Support for move semantics in library containers is a better reason for disallowing it, I'm just pointing out that std::move (and std::forward) is the simplest part of the puzzle.
