Is a local variable an lvalue when deducing its type using decltype?

Viewed 77

I am reading the Wikipedia entry about decltype, and I can't understand the following passage:

Similarly to the sizeof operator, the operand of decltype is unevaluated.[11] Informally, the type returned by decltype(e) is deduced as follows:[2]

  1. If the expression e refers to a variable in local or namespace scope, a static member variable or a function parameter, then the result is that variable's or parameter's declared type
  2. Otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e; if e is an xvalue, the result is T&&; otherwise, e is a prvalue and the result is T.

it first says: "If the expression e refers to a variable in local or namespace scope", then it follows by "Otherwise, if e is an lvalue". For me it implies that a variable from local scope is not an lvalue. Am I right? - I always thought local variables are lvalues.

Maybe item 2 refers to case where we use decltype((e)) - with double parentheses? I suppose this is what is said later in this wiki: "More formally, Rule 1 applies to unparenthesized id-expressions and class member access expressions."

1 Answers

For me it implies that variable from local scope is not an lvalue

No, that's not the correct way to read it. The list is not a bunch of mutually exclusive options. Some properties may overlap. When determining the type decltype produces, we are meant to apply the first item whose condition is satisfied. Think of it like an algorithm, a program to determine how decltype should behave (and since the standard is a technical specification, it pretty much is that).

if (e is the unparenthesized name of a variable ...)
  result = declared type of e
else if (e is an lvalue expression)
  result = type of e &
else if (e is an xvalue expression)
  result = type of e &&
else
  result = type of e

Obviously just like in a C++ program, more than one condition may be true. But (also like a C++ program) we simply go with the first branch whose condition is satisfied.

Related