I'm having some difficulty interpreting bullet point (5.2.1.1) in paragraph §8.5.3/5 of N4140

Question

The snippet below compiles

#include <iostream>
int& f() { static int i = 100; std::cout << i << '\n'; return i; }

int main()
{
    int& r = f();
    r = 101;
    f();
}

and print the values ( live example )

100
101

Now, reading §8.5.3/5 in N4140, I can see that it compiles because of bullet point (5.1.1), that is, the reference is an lvalue reference, the initializer expression is an lvalue and int is reference-compatible with int (or with int& - I don't know for sure which one I should use here).

Bullet points (5.1) and (5.1.1):

— If the reference is an lvalue reference and the initializer expression

  — is an lvalue (but is not a bit-field), and “cv1 T1” is reference-compatible with “cv2 T2,” or ... 

Now suppose I change the left value reference in the declaration int& r = f(); by a right value reference, ie, int&& r = f(); . I know the code won't compile, as an rvalue reference doesn't bind to an lvalue. But what I'm curious is, how to reach this conclusion using the Standard?

I'll explain what are my difficulties:

1. Clearly int&& r = f(); is covered by bullet point (5.2), because the reference is an rvalue reference.

Bullet point (5.2):

— Otherwise, the reference shall be an lvalue reference to a non-volatile const type (ie, cv1 shall be const), or the reference shall be an rvalue reference.

2. In principle, I would say that (5.2.1.1) supports this initialization as the initializer is a function lvalue and int is reference compatible with int (or with int& ).

Bullet points (5.2.1) and (5.2.1.1):

— If the initializer expression

 — is an xvalue (but not a bit-field), class prvalue, array prvalue or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or ... 

Edit

I've included the bullet points verbatim from N4140 (C++14), which are equivalent to similar bullet points in N3337 (C++11).

Answer 1

the initializer expression is an lvalue and int is reference-compatible with int (or with int& - I don't know for sure which one I should use here).

Reference-compatibility is a relation applied to the type referred to, not the reference type. For example, [dcl.init.ref]/5 talks about intializing "a reference to type cv1 T1 by an expression of type cv2 T2 ", and later compares eg "where T1 is not reference-related to T2 ".

The type of the expression f() is just int , despite the fact that the return type of f is int& . Expressions simply do not have reference type when we observe them ^(*) ; the reference is stripped and used to determine the value category (see [expr]/5). For int& f() , the expression f() is an lvalue; for int g() , the expression g() is an rvalue.

_{^(*) To be perfectly precise, expressions can have reference type in the Standard , but only as the "initial" resulting type. The reference is dropped "prior to any further analysis", which implies that this referencess is simply not observable through the type.}

---

Now suppose I change the left value reference in the declaration int& r = f(); by a right value reference, ie, int&& r = f(); . I know the code won't compile, as an rvalue reference doesn't bind to an lvalue. But what I'm curious is, how to reach this conclusion using the Standard?

The confusion, as it seems from the discussion in the comments, seems to be that f() is not a function lvalue. Value categories such as "lvalue" and "rvalue" are properties of expressions. The term "function lvalue" must therefore refer to an expression, namely an expression of function type with the value category "lvalue" .

But the expression f() is a function call expression . Grammatically, it's a postfix-expression , the postfix being the function argument list. As per [expr.call]/10:

A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise.

And [expr.call]/3

If the postfix-expression designates a destructor [...]; otherwise, the type of the function call expression is the return type of the statically chosen function [...]

That is, the (observed ^{see above} ) type of the expression f() is int , and the value category is "lvalue". Note that the (observed) type is not int& .

A function lvalue is for example an id-expression like f , the result of indirecting a function pointer, or an expression yielding any kind of reference to function:

using ft = void();
void f();
ft&  l();
ft&& r();
ft*  p();

// function lvalue expressions:
f
l()
r()
*p()

[expr.prim.general]/8 specifies that those identifiers like f are, as id-expressions , lvalues:

An identifier is an id-expression provided it has been suitably declared. [...] The type of the expression is the type of the identifier . The result is the entity denoted by the identifier. The result is an lvalue if the entity is a function, variable, or data member and a prvalue otherwise.

---

Back to the example int&& r = f(); . Using some post-N4296 draft.

[dcl.init.ref]

⁵ A reference to type “ cv1 T1 ” is initialized by an expression of type “ cv2 T2 ” as follows:

• (5.1) If the reference is an lvalue reference and the initializer expression

The reference is an rvalue reference. 5.1 does not apply.

• (5.2) Otherwise, the reference shall be an lvalue reference to a non-volatile const type (ie, cv1 shall be const ), or the reference shall be an rvalue reference. [example omitted]

This applies, the reference is an rvalue-reference.

• (5.2.1) If the initializer expression
  • (5.2.1.1) is an xvalue (but not a bit-field), class prvalue, array prvalue or function lvalue and [...], or
  • (5.2.1.2) has a class type (ie, T2 is a class type) [...]

The initializer is an lvalue of type int . 5.2.1 does not apply.

• (5.2.2) Otherwise:
  • (5.2.2.1) If T1 or T2 is a class type [...]
  • (5.2.2.2) Otherwise, a temporary of type “ cv1 T1 ” is created and copy-initialized (dcl.init) from the initializer expression. The reference is then bound to the temporary.

Finally, 5.2.2.2 applies. However:

If T1 is reference-related to T2 :

• (5.2.2.3) cv1 shall be the same cv-qualification as, or greater cv-qualification than, cv2 ; and
• (5.2.2.4) if the reference is an rvalue reference, the initializer expression shall not be an lvalue.

T1 and T2 are int (the reference of the return type of f() is removed and used only to determine the value category), so they're reference-related. cv1 and cv2 are both empty. The reference is an rvalue reference, and f() is an lvalue, hence 5.2.2.4 renders the program ill-formed.

---

The reason why the term "function lvalue" appears in 5.2.1.1 might be related to the problem of "function rvalues" (see, for example, N3010 - Rvalue References as "Funny" Lvalues ). There were no function rvalues in C++03, and it seems the committee didn't want to introduce them in C++11. Without rvalue references, I think it's impossible to get a function rvalue. For example, you may not cast to a function type, and you may not return function types from a function.

Probably for consistency, function lvalues can be bound to rvalue references to function types via a cast:

template<typename T>
void move_and_do(T& t)
{
    T&& r = static_cast<T&&>(t); // as if moved
}

int i = 42;
move_and_do(i);

move_and_do(f);

But for T being a function type like void() , the value category of static_cast<T&&>(t) is lvalue (there are no rvalues of function type). Hence, rvalue references to function types can bind to function lvalues.