It's annoying how arbitrary the rules for value categories are.

• casting a value as an rvalue reference is an xvalue since it is an addressable result available to the programmer but the result is also temporary. Ok.

• then casting something as an lvalue reference should be the same, right? Wrong. It is an lvalue because the standard says it is. Ok.

• temporary values, even if they have an address, are still rvalues even if the address is not made available to the programmer (this most often occurs when you return an object from a function call). okay, fine.

• but string literals are lvalues??? & is defined on a string literal? why? why only for string literals and not all objects??????

• accessing an element of an array from an expression for an array that is, itself an rvalue (ie, get_array()[0]) is an xvalue, not a prvalue. I guess, by definition, arrays elements are inherently addressable data available to me so sure, why not.

• but get_object().property is also an xvalue. why. why is it an xvalue. even though objects have addresses they are not exposed to the user if they are temporary so why is the property access now considered addressable??????

I truly don't think it's possible to derive in the general case whether something is a prvalue, xvalue, or lvalue from first principles. For a lot of cases you just have to see what the standard says they are and try to make sense of it.

Maybe if I understood more about compilers there could be good reasons for these value categories but then again, if the language can only be properly understood by understanding implementation details of its compiler then it is not an effective programming language imo.

@wallhackio re: the last one, object purropurrties have addresses; by accessing a purropurrty on an object you are implicitly claiming that that purropurrty is addressable. that’s just how objects work

@aescling but is that address exposed to the programmer?