I have a very basic question: is it a good idea to return a std::vector<A> using std::move? For, example:
class A {}; std::vector<A> && func() { std::vector<A> v; /* fill v */ return std::move(v); } Should I return std::map, std::list.. etc... in this way?
You declare a function to return by r-value reference - this should almost never be done (if you return the local object by reference, you will end up with a dangling reference). Instead declare the function to return by value. This way the caller's value will be move constructed by the r-value returned by the function. The returned value will also bind to any reference.
Secondly, no, you should not return using an explicit std::move as this will prevent the compiler to use RVO. There's no need as the compiler will automatically convert any l-value reference returned to an r-value reference if possible.
std::vector<A> func() { std::vector<A> v; /* fill v */ return v; // 'v' is converted to r-value and return value is move constructed. } 
std::vector, std::map, and std::list (see the question), which neither have their copy ctor deleted. There are of course other objects that need an explicit std::move, e.g. std::unique_ptr etc. Using an explicit move represent resource ownership transfer for cases where copying is disallowed by design, not optimization of return values. And btw, basically all compilers supported RVO during the C++11 era, even though it was not guaranteed by the standard :)std::move in C++11 if returning by value (if the move ctor is not user defined in this case, it would not be implicitly defined and you would get an error anyway). This all seems to be the exceptional case though.No, it's not. This will in fact prevent copy elision in some cases. There is even a warning in some compilers about it, called -Wpessimizing-move.
In agreement with other answers, just return it by value, changing the return type to simply be std::vector<A>, and the compiler will take care of calling the move constructor when needed.
You could take a look at this post I just found, which seems to explain it in much detail (although I haven't read it through myself): https://vmpstr.blogspot.hu/2015/12/redundant-stdmove.html
std::move" as well as "change the return type."Both gcc and clang compiler with enabled optimization generate same binary code for both case when you return local variable and when you write std::move(). Just return a value.
But using && and noexcept specifier is useful if you create moving constructor and moving operator= for your custom class
std::vector<A> & v;?? are you sure about that ?