A: 

The A is an rvalue. The array inside it isn't. Imagine the case in which you have a method chain on that temporary object - the variables within it live for more than one method call and return, and they may pass references (valid for the duration of the chain) to other functions. Those functions cannot know in advance that they shall be called upon an rvalue.

In the latest version of the draft, you can overload functions on rvalue/lvalue *this. However, even then, an rvalue reference does not make the contents of what is referred to an rvalue, and I'm not entirely sure that ANY compiler currently supports this, and I know that MSVC doesn't.

Infact, using decltype, you can determine easily that the compiler calls that array an lvalue.

Consider:

template<typename A, typename B> auto sum(A&& a, B&& b) -> decltype(std::forward<A>(a) + std::forward<B>(b)) {
    return std::forward<A>(a) + std::forward<B>(b);
}

That's what decltype was for, and it most definitely differentiates between lvalues and rvalues. Alternatively, consider this:

int main()
{
    auto var = f().a;
}

Var is an int*. That's an instant fail, since f().a immediately dies. Not sure of my immediate opinion on that, but it's certainly not valid for an rvalue.

DeadMG
decltype does not differentiate between rvalues and lvalues. and please read my second quote from the standard once more.
Armen Tsirunyan
@Armen: The entire point of decltype is to differentiate. How else could perfect forwarding even begin to work?
DeadMG
@DeadMG decltype(expr) is the type of the expr. whether or not expr is an lvalue or rvalue has nothing to do with its type.
Armen Tsirunyan
Alf P. Steinbach
Johannes Schaub - litb
I hate decltype and auto. They never seem to produce sensible results.
DeadMG
Actually, my decltype explanation is still simplified as there are more special cases for `decltype` anyway :)
Johannes Schaub - litb
+4  A: 

Yes, you are correct. The expression is an rvalue of array type. This is not a defect - the committee knows about it, and it was also a common issue in C89, which only allows conversion to pointers for lvalues of array types. As a consequence, you could not index or dereference an array like f().a. C99 fixed this, and C++ does not have a problem with it.

Note that whether or not it is an rvalue is independent to whether or not the expression denotes an object. C++03 accidentally omitted to say that an rvalue expression that is of array type denotes an object. This was fixed in C++0x by DR#450.

(obviously appreciating that there are no rvalues of such)

There are actually rvalues of function types. These occur for non-static member functions denoted by a class member access expression

struct A { void f(); };

/* A().f is an rvalue of type "void()" */
int main() { A().f(); }
Johannes Schaub - litb
Thanks! So do you know if this is the only case of rvalue arrays, that is made by . or ->. Are there other examples?
Armen Tsirunyan
@Armen I can't think of another case (for C++03).
Johannes Schaub - litb
@Armen note that as a consequence, Comeau says that `A().a` is of type `int[4]`, even if you declared the array as `const int a[4];`. That's because the Standard says rvalues of non-class types are never cv-qualified, and because the EDG frontend takes cv-qualification of arrays and their element types as bidirectionally equivalent (see core issue #1059).
Johannes Schaub - litb
@Johannes: Excellent answer. +100 for the const example! And the function rvalue example.
Armen Tsirunyan
That's cool!. A mystery solved.
Chubsdad