Is an lvalue reference subjected to an lvalue-to-rvalue-conversion? - c++

I always thought that a reference would be subjected to an lvalue-to-rvalue-conversion, as any other glvalue, when used in an expression. Nevertheless, it seems like, every time a reference is used in an expression, it is handled in bullet point (2.9) of [expr.const]/2 instead of bullet point (2.7) (in C++14, or C++1z).
Take for example the reference r below, used to initialize variable j. Is it subjected to an lvalue-to-rvalue-conversion?
const int i = 1;
constexpr int& r = i
constexpr int j = r;
According to this answer the reference r is handled in bullet point (2.9) of [expr.const]/2 and not in bullet point 2.7, as I would expect. Why is this?


In some contexts the lvalue-to-rvalue conversion occurs because it is explicitly specified to occur in a given context (for example, for the ternary conditional operator, see here). But it is listed in clause 4 so it is an implicit standard conversion; like all other implicit standard conversions, it occurs when needed. For example, a glvalue of type int will be implicitly converted to a prvalue when used as the operand of an arithmetic expression since its stored value is required.
In the case of constexpr int j = r, yes, the glvalue expression r undergoes lvalue-to-rvalue conversion, since this initialization requires the stored value. Although it isn't explicitly specified that reading the stored value of an object invokes an lvalue-to-rvalue conversion, this fact must obviously be true in the context of the entire standard, as well as the C standard, where the term "rvalue" is not used, but instead the analogous concept of the lvalue conversion refers to the conversion of an lvalue into "the value stored in the designated object".

Related

Why cannot a prvalue of array type initialize an object of the same type? [duplicate]

Here is some code:
int main()
{
using T = int[3];
T a;
a = T{};
}
As far as I can tell, this code is correct according to the C++17 Standard, however every compiler I tried rejected it.
Is this code actually incorrect? If so, by what clauses of the Standard?
My investigation so far: In C and in older versions of C++, the code was incorrect because the assignment operator's left operand must be a modifiable lvalue, which a either wasn't, or it was unclearly specified. But since C++17 a is clearly specified as a modifiable lvalue (C++17 [basic.lval]/7).
The array-to-pointer conversion is not applied here: [expr.ass] doesn't explicitly specify it, and [expr]/9 and [expr]/10 don't seem to apply: the = expects a prvalue as right operand, and a prvalue was provided. (And it expects a glvalue as left operand, and a glvalue was provided). Those clauses apply if a glvalue was supplied where a prvalue was expected or vice versa.
[expr.ass]/3 says the right expression is implicitly converted to the type of the left operand . But since both sides have identical type int[3] no conversion seems to be necessary.
So I see no clauses which would exclude [expr.ass]/2 from applying, that the value of the right-hand side is stored in the object referred to by the left.
The latest draft moves around the clauses that were in [basic.lval]/7 and [expr]/9-10 but doesn't seem to change their meaning, and it even re-words [expr.ass]/2 to be clearer:
In simple assignment (=), the object referred to by the left operand is modified by replacing its value with the result of the right operand.

As far as I can tell, the definition of "modifiable lvalue" is either under-specified in C++, or arrays have been intentionally been specified to be assignable (I suspect that former is true, since no compiler does latter).
The standard (latest draft) says:
[basic.lval]
An lvalue is modifiable unless its type is const-qualified or is a function type.
This is quite concise, but there is no exclusion of arrays.
Furthermore, this hasn't changed through standard versions at least since C++03, which specifies following:
[basic.lval]
11 Functions cannot be modified, but pointers to functions can be modifiable.
12 A pointer to an incomplete type can be modifiable. ...
13 The referent of a const-qualified expression shall not be modified ...
Which is mostly same, except using more descriptive than definitive wording. No exclusion of arrays.
By contrast, C11 standard is crystal clear (quoting N1548 draft):
6.3.2.1 Lvalues, arrays, and function designators
1 ... A modifiable lvalue is an lvalue that does not have array type, ...

Because built-in operators are also governed by [over.built], that is:
The candidate operator functions that represent the built-in operators defined in Clause [expr] are specified in this subclause.
For assignment operator, the forms of the corresponding functions are:
over.built#19
For every triple (L, vq, R), where L is an arithmetic type, and R is a promoted arithmetic type, there exist candidate operator functions of the form
For every pair (T, vq), where T is any type, there exist candidate operator functions of the form
Tvq& operator=(T vq&, T*);
For every pair (T, vq), where T is an enumeration or pointer to member type, there exist candidate operator functions of the form
vq T& operator=(vq T&, T);
Hence, neither of them could be as the candidate function when the corresponding arguments are a, T{}. So, the program should be ill-formed.

There is no provision in the C++ Standard for the materialization of a prvalue array, as you can see in Note 3 of [class.temporary]/5, which summarizes the cases where these materializations occur.

Does discarding a value result in reading it?

Consider the following example:
{
int x;
(void)x; // silence the "unused" warning
...
}
Does this lead to undefined behavior due to x being read uninitialized? If yes, then does this mean that in the following code a memory read instruction (to read the pointee) must be emitted by the compiler?
volatile char* p=getP();
(void)*p;
I'm interested in both the C and C++ rules regarding this, in case they differ.

In C++, an access is coupled with a lvalue-to-rvalue conversion. This conversion is what takes an "identity" and produces its value. On the subject of discarded value expressions, the C++ standard says this:
[expr] (emphasis mine)
12 In some contexts, an expression only appears for its side
effects. Such an expression is called a discarded-value expression.
The array-to-pointer and function-to-pointer standard conversions are
not applied. The lvalue-to-rvalue conversion is applied if and only if
the expression is a glvalue of volatile-qualified type and it is one
of the following:
( expression ), where expression is one of these expressions,
id-expression,
subscripting,
class member access,
indirection,
pointer-to-member operation,
conditional expression where both the second and the third operands are one of these expressions, or
comma expression where the right operand is one of these expressions.
[ Note: Using an overloaded operator causes a function call; the above
covers only operators with built-in meaning.  — end note ] If the
expression is a prvalue after this optional conversion, the temporary
materialization conversion is applied. [ Note: If the expression is an
lvalue of class type, it must have a volatile copy constructor to
initialize the temporary that is the result object of the
lvalue-to-rvalue conversion.  — end note ] The glvalue expression is
evaluated and its value is discarded.
In the non-volatile case, there is no lvalue-to-rvalue conversion. Therefore we can say with confidence the variable is not accessed.
In the volatile case however, you have indirection inside the cast-expression, and that undergoes a lvalue-to-rvalue conversion. As such, the volatile is read, and you get undefined behavior out of reading an uninitialized object.
To avoid the undefined behavior around volatile glvalues, one can annotate the relevant variables as [[maybe_unused]]. That is the sanctioned way, and is the one I'd prefer over a cast in the non-volatile case too.

Relevant part from the C standard:
6.3.2.2 void
The (nonexistent) value of a void expression (an expression that has type void) shall not
be used in any way, and implicit or explicit conversions (except to void) shall not be
applied to such an expression. If an expression of any other type is evaluated as a void
expression, its value or designator is discarded. (A void expression is evaluated for its
side effects.)
Where side-effects are defined by 5.1.2.3/2:
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.
Reading a non-volatile variable is not a side-effect.
That is, if accessing x is a side-effect, then the code must be evaluated (executed). This is only the case when x is volatile. So (void)x; will not trigger undefined behavior.
Otherwise it would have been undefined behavior to use the local variable x, because its address is never taken anywhere inside the scope.
In case of *p you have a clear lvalue access of a volatile-qualified variable through the * operator, so the compiler must read the variable. Regardless of the cast to (void).
The example below would also be evaluated, but invokes undefined behavior (unless the address of the pointer p itself is taken):
char* volatile p;
(void)p;

Assignment to array in C++17

Here is some code:
int main()
{
using T = int[3];
T a;
a = T{};
}
As far as I can tell, this code is correct according to the C++17 Standard, however every compiler I tried rejected it.
Is this code actually incorrect? If so, by what clauses of the Standard?
My investigation so far: In C and in older versions of C++, the code was incorrect because the assignment operator's left operand must be a modifiable lvalue, which a either wasn't, or it was unclearly specified. But since C++17 a is clearly specified as a modifiable lvalue (C++17 [basic.lval]/7).
The array-to-pointer conversion is not applied here: [expr.ass] doesn't explicitly specify it, and [expr]/9 and [expr]/10 don't seem to apply: the = expects a prvalue as right operand, and a prvalue was provided. (And it expects a glvalue as left operand, and a glvalue was provided). Those clauses apply if a glvalue was supplied where a prvalue was expected or vice versa.
[expr.ass]/3 says the right expression is implicitly converted to the type of the left operand . But since both sides have identical type int[3] no conversion seems to be necessary.
So I see no clauses which would exclude [expr.ass]/2 from applying, that the value of the right-hand side is stored in the object referred to by the left.
The latest draft moves around the clauses that were in [basic.lval]/7 and [expr]/9-10 but doesn't seem to change their meaning, and it even re-words [expr.ass]/2 to be clearer:
In simple assignment (=), the object referred to by the left operand is modified by replacing its value with the result of the right operand.

As far as I can tell, the definition of "modifiable lvalue" is either under-specified in C++, or arrays have been intentionally been specified to be assignable (I suspect that former is true, since no compiler does latter).
The standard (latest draft) says:
[basic.lval]
An lvalue is modifiable unless its type is const-qualified or is a function type.
This is quite concise, but there is no exclusion of arrays.
Furthermore, this hasn't changed through standard versions at least since C++03, which specifies following:
[basic.lval]
11 Functions cannot be modified, but pointers to functions can be modifiable.
12 A pointer to an incomplete type can be modifiable. ...
13 The referent of a const-qualified expression shall not be modified ...
Which is mostly same, except using more descriptive than definitive wording. No exclusion of arrays.
By contrast, C11 standard is crystal clear (quoting N1548 draft):
6.3.2.1 Lvalues, arrays, and function designators
1 ... A modifiable lvalue is an lvalue that does not have array type, ...

Because built-in operators are also governed by [over.built], that is:
The candidate operator functions that represent the built-in operators defined in Clause [expr] are specified in this subclause.
For assignment operator, the forms of the corresponding functions are:
over.built#19
For every triple (L, vq, R), where L is an arithmetic type, and R is a promoted arithmetic type, there exist candidate operator functions of the form
For every pair (T, vq), where T is any type, there exist candidate operator functions of the form
Tvq& operator=(T vq&, T*);
For every pair (T, vq), where T is an enumeration or pointer to member type, there exist candidate operator functions of the form
vq T& operator=(vq T&, T);
Hence, neither of them could be as the candidate function when the corresponding arguments are a, T{}. So, the program should be ill-formed.

There is no provision in the C++ Standard for the materialization of a prvalue array, as you can see in Note 3 of [class.temporary]/5, which summarizes the cases where these materializations occur.

Why do lvalue-to-rvalue conversions exist? Why are they required? [duplicate]

I see the term "lvalue-to-rvalue conversion" used in many places throughout the C++ standard. This kind of conversion is often done implicitly, as far as I can tell.
One unexpected (to me) feature of the phrasing from the standard is that they decide to treat lvalue-to-rvalue as a conversion. What if they had said that a glvalue is always acceptable instead of a prvalue. Would that phrase actually have a different meaning? For example, we read that lvalues and xvalues are examples of glvalues. We don't read that lvalues and xvalues are convertible to glvalues. Is there a difference in meaning?
Before my first encounter with this terminology, I used to model lvalues and rvalues mentally more or less as follows: "lvalues are always able to act as rvalues, but in addition can appear on the left side of an =, and to the right of an &".
This, to me, is the intuitive behavior that if I have a variable name, then I can put that name everywhere where I would have put a literal. This model seems consistent with lvalue-to-rvalue implicit conversions terminology used in the standard, as long as this implicit conversion is guaranteed to happen.
But, because they use this terminology, I started wondering whether the implicit lvalue-to-rvalue conversion may fail to happen in some cases. That is, maybe my mental model is wrong here. Here is a relevant part of the standard: (thanks to the commenters).
Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see 4.1, 4.2, and 4.3. [Note: An attempt to bind an rvalue reference to an lvalue is not such a context; see 8.5.3 .—end note]
I understand what they describe in the note is the following:
int x = 1;
int && y = x; //in this declaration context, x won't bind to y.
// but the literal 1 would have bound, so this is one context where the implicit
// lvalue to rvalue conversion did not happen.
// The expression on right is an lvalue. if it had been a prvalue, it would have bound.
// Therefore, the lvalue to prvalue conversion did not happen (which is good).
So, my question is (are):
1) Could someone clarify the contexts where this conversion can happen implicitly? Specifically, other than the context of binding to an rvalue reference, are there any other where lvalue-to-rvalue conversions fail to happen implicitly?
2) Also, the parenthetical [Note:...] in the clause makes it seem that we could have figured it out from the sentence before. Which part of the standard would that be?
3) Does that mean that rvalue-reference binding is not a context where we expect a prvalue expression (on the right)?
4) Like other conversions, does the glvalue-to-prvalue conversion involve work at runtime that would allow me to observe it?
My aim here is not to ask if it is desirable to allow such a conversion. I'm trying to learn to explain to myself the behavior of this code using the standard as starting point.
A good answer would go through the quote I placed above and explain (based on parsing the text) whether the note in it is also implicit from its text. It would then maybe add any other quotes that let me know the other contexts in which this conversion may fail to happen implicitly, or explain there are no more such contexts. Perhaps a general discussion of why glvalue to prvalue is considered a conversion.

I think the lvalue-to-rvalue conversion is more than just use an lvalue where an rvalue is required. It can create a copy of a class, and always yields a value, not an object.
I'm using n3485 for "C++11" and n1256 for "C99".
Objects and values
The most concise description is in C99/3.14:
object
region of data storage in the execution environment, the contents of which can represent
values
There's also a bit in C++11/[intro.object]/1
Some objects are polymorphic; the implementation generates information associated with
each such object that makes it possible to determine that object’s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions used to access them.
So an object contains a value (can contain).
Value categories
Despite its name, value categories classify expressions, not values. lvalue-expressions even cannot be considered values.
The full taxonomy / categorization can be found in [basic.lval]; here's a StackOverflow discussion.
Here are the parts about objects:
An lvalue ([...]) designates a function or an object. [...]
An xvalue (an “eXpiring” value) also refers to an object [...]
A glvalue (“generalized” lvalue) is an lvalue or an xvalue.
An rvalue ([...]) is an xvalue, a temporary object or subobject thereof, or a value that is not associated with an object.
A prvalue (“pure” rvalue) is an rvalue that is not an xvalue. [...]
Note the phrase "a value that is not associated with an object". Also note that as xvalue-expressions refer to objects, true values must always occur as prvalue-expressions.
The lvalue-to-rvalue conversion
As footnote 53 indicates, it should now be called "glvalue-to-prvalue conversion". First, here's the quote:
1 A glvalue of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program
that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.
This first paragraph specifies the requirements and the resulting type of the conversion. It isn't yet concerned with the effects of the conversion (other than Undefined Behaviour).
2 When an lvalue-to-rvalue conversion occurs in an unevaluated operand or a subexpression thereof the value contained in the referenced object is not accessed. Otherwise, if the glvalue has a class type, the conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary. Otherwise, if the glvalue has (possibly cv-qualified) type std::nullptr_t, the
prvalue result is a null pointer constant. Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
I'd argue that you'll see the lvalue-to-rvalue conversion most often applied to non-class types. For example,
struct my_class { int m; };
my_class x{42};
my_class y{0};
x = y;
The expression x = y does not apply the lvalue-to-rvalue conversion to y (that would create a temporary my_class, by the way). The reason is that x = y is interpreted as x.operator=(y), which takes y per default by reference, not by value (for reference binding, see below; it cannot bind an rvalue, as that would be a temporary object different from y). However, the default definition of my_class::operator= does apply the lvalue-to-rvalue conversion to x.m.
Therefore, the most important part to me seems to be
Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
So typically, an lvalue-to-rvalue conversion will just read the value from an object. It isn't just a no-op conversion between value (expression) categories; it can even create a temporary by calling a copy constructor. And the lvalue-to-rvalue conversion always returns a prvalue value, not a (temporary) object.
Note that the lvalue-to-rvalue conversion is not the only conversion that converts an lvalue to a prvalue: There's also the array-to-pointer conversion and the function-to-pointer conversion.
values and expressions
Most expressions don't yield objects[[citation needed]]. However, an id-expression can be an identifier, which denotes an entity. An object is an entity, so there are expressions which yield objects:
int x;
x = 5;
The left hand side of the assignment-expression x = 5 also needs to be an expression. x here is an id-expression, because x is an identifier. The result of this id-expression is the object denoted by x.
Expressions apply implicit conversions: [expr]/9
Whenever a glvalue expression appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue, array-to-pointer, or function-to-pointer standard conversions are applied to convert the expression to a prvalue.
And /10 about usual arithmetic conversions as well as /3 about user-defined conversions.
I'd love now to quote an operator that "expects a prvalue for that operand", but cannot find any but casts. For example, [expr.dynamic.cast]/2 "If T is a pointer type, v [the operand] shall be a prvalue of a pointer to complete class type".
The usual arithmetic conversions required by many arithmetic operators do invoke an lvalue-to-rvalue conversion indirectly via the standard conversion used. All standard conversions but the three that convert from lvalues to rvalues expect prvalues.
The simple assignment however doesn't invoke the usual arithmetic conversions. It is defined in [expr.ass]/2 as:
In simple assignment (=), the value of the expression replaces that of the object referred to by the left operand.
So although it doesn't explicitly require a prvalue expression on the right hand side, it does require a value. It is not clear to me if this strictly requires the lvalue-to-rvalue conversion. There's an argument that accessing the value of an uninitialized variable should always invoke undefined behaviour (also see CWG 616), no matter if it's by assigning its value to an object or by adding its value to another value. But this undefined behaviour is only required for an lvalue-to-rvalue conversion (AFAIK), which then should be the only way to access the value stored in an object.
If this more conceptual view is valid, that we need the lvalue-to-rvalue conversion to access the value inside an object, then it'd be much easier to understand where it is (and needs to be) applied.
Initialization
As with simple assignment, there's a discussion whether or not the lvalue-to-rvalue conversion is required to initialize another object:
int x = 42; // initializer is a non-string literal -> prvalue
int y = x; // initializer is an object / lvalue
For fundamental types, [dcl.init]/17 last bullet point says:
Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. Standard conversions will be used, if necessary, to convert the initializer expression to the cv-unqualified version of the destination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed.
However, it also mentioned the value of the initializer expression. Similar to the simple-assignment-expression, we can take this as an indirect invocation of the lvalue-to-rvalue conversion.
Reference binding
If we see lvalue-to-rvalue conversion as a way to access the value of an object (plus the creation of a temporary for class type operands), we understand that it's not applied generally for binding to a reference: A reference is an lvalue, it always refers to an object. So if we bound values to references, we'd need to create temporary objects holding those values. And this is indeed the case if the initializer-expression of a reference is a prvalue (which is a value or a temporary object):
int const& lr = 42; // create a temporary object, bind it to `r`
int&& rv = 42; // same
Binding a prvalue to an lvalue reference is prohibited, but prvalues of class types with conversion functions that yield lvalue references may be bound to lvalue references of the converted type.
The complete description of reference binding in [dcl.init.ref] is rather long and rather off-topic. I think the essence of it relating to this question is that references refer to objects, therefore no glvalue-to-prvalue (object-to-value) conversion.

On glvalues: A glvalue ("generalized" lvalue) is an expression that is either an lvalue or an xvalue.
A glvalue may be implicitly converted to prvalue with lvalue-to-rvalue, array-to-pointer, or function-to-pointer implicit conversion.
Lvalue transformations are applied when lvalue argument (e.g. reference to an object) is used in context where rvalue (e.g. a number) is expected.
Lvalue to rvalue conversion
A glvalue of any non-function, non-array type T can be implicitly converted to prvalue of the same type. If T is a non-class type, this conversion also removes cv-qualifiers. Unless encountered in unevaluated context (in an operand of sizeof, typeid, noexcept, or decltype), this conversion effectively copy-constructs a temporary object of type T using the original glvalue as the constructor argument, and that temporary object is returned as a prvalue. If the glvalue has the type std::nullptr_t, the resulting prvalue is the null pointer constant nullptr.

lvalue to rvalue implicit conversion

I see the term "lvalue-to-rvalue conversion" used in many places throughout the C++ standard. This kind of conversion is often done implicitly, as far as I can tell.
One unexpected (to me) feature of the phrasing from the standard is that they decide to treat lvalue-to-rvalue as a conversion. What if they had said that a glvalue is always acceptable instead of a prvalue. Would that phrase actually have a different meaning? For example, we read that lvalues and xvalues are examples of glvalues. We don't read that lvalues and xvalues are convertible to glvalues. Is there a difference in meaning?
Before my first encounter with this terminology, I used to model lvalues and rvalues mentally more or less as follows: "lvalues are always able to act as rvalues, but in addition can appear on the left side of an =, and to the right of an &".
This, to me, is the intuitive behavior that if I have a variable name, then I can put that name everywhere where I would have put a literal. This model seems consistent with lvalue-to-rvalue implicit conversions terminology used in the standard, as long as this implicit conversion is guaranteed to happen.
But, because they use this terminology, I started wondering whether the implicit lvalue-to-rvalue conversion may fail to happen in some cases. That is, maybe my mental model is wrong here. Here is a relevant part of the standard: (thanks to the commenters).
Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see 4.1, 4.2, and 4.3. [Note: An attempt to bind an rvalue reference to an lvalue is not such a context; see 8.5.3 .—end note]
I understand what they describe in the note is the following:
int x = 1;
int && y = x; //in this declaration context, x won't bind to y.
// but the literal 1 would have bound, so this is one context where the implicit
// lvalue to rvalue conversion did not happen.
// The expression on right is an lvalue. if it had been a prvalue, it would have bound.
// Therefore, the lvalue to prvalue conversion did not happen (which is good).
So, my question is (are):
1) Could someone clarify the contexts where this conversion can happen implicitly? Specifically, other than the context of binding to an rvalue reference, are there any other where lvalue-to-rvalue conversions fail to happen implicitly?
2) Also, the parenthetical [Note:...] in the clause makes it seem that we could have figured it out from the sentence before. Which part of the standard would that be?
3) Does that mean that rvalue-reference binding is not a context where we expect a prvalue expression (on the right)?
4) Like other conversions, does the glvalue-to-prvalue conversion involve work at runtime that would allow me to observe it?
My aim here is not to ask if it is desirable to allow such a conversion. I'm trying to learn to explain to myself the behavior of this code using the standard as starting point.
A good answer would go through the quote I placed above and explain (based on parsing the text) whether the note in it is also implicit from its text. It would then maybe add any other quotes that let me know the other contexts in which this conversion may fail to happen implicitly, or explain there are no more such contexts. Perhaps a general discussion of why glvalue to prvalue is considered a conversion.

I think the lvalue-to-rvalue conversion is more than just use an lvalue where an rvalue is required. It can create a copy of a class, and always yields a value, not an object.
I'm using n3485 for "C++11" and n1256 for "C99".
Objects and values
The most concise description is in C99/3.14:
object
region of data storage in the execution environment, the contents of which can represent
values
There's also a bit in C++11/[intro.object]/1
Some objects are polymorphic; the implementation generates information associated with
each such object that makes it possible to determine that object’s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions used to access them.
So an object contains a value (can contain).
Value categories
Despite its name, value categories classify expressions, not values. lvalue-expressions even cannot be considered values.
The full taxonomy / categorization can be found in [basic.lval]; here's a StackOverflow discussion.
Here are the parts about objects:
An lvalue ([...]) designates a function or an object. [...]
An xvalue (an “eXpiring” value) also refers to an object [...]
A glvalue (“generalized” lvalue) is an lvalue or an xvalue.
An rvalue ([...]) is an xvalue, a temporary object or subobject thereof, or a value that is not associated with an object.
A prvalue (“pure” rvalue) is an rvalue that is not an xvalue. [...]
Note the phrase "a value that is not associated with an object". Also note that as xvalue-expressions refer to objects, true values must always occur as prvalue-expressions.
The lvalue-to-rvalue conversion
As footnote 53 indicates, it should now be called "glvalue-to-prvalue conversion". First, here's the quote:
1 A glvalue of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program
that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.
This first paragraph specifies the requirements and the resulting type of the conversion. It isn't yet concerned with the effects of the conversion (other than Undefined Behaviour).
2 When an lvalue-to-rvalue conversion occurs in an unevaluated operand or a subexpression thereof the value contained in the referenced object is not accessed. Otherwise, if the glvalue has a class type, the conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary. Otherwise, if the glvalue has (possibly cv-qualified) type std::nullptr_t, the
prvalue result is a null pointer constant. Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
I'd argue that you'll see the lvalue-to-rvalue conversion most often applied to non-class types. For example,
struct my_class { int m; };
my_class x{42};
my_class y{0};
x = y;
The expression x = y does not apply the lvalue-to-rvalue conversion to y (that would create a temporary my_class, by the way). The reason is that x = y is interpreted as x.operator=(y), which takes y per default by reference, not by value (for reference binding, see below; it cannot bind an rvalue, as that would be a temporary object different from y). However, the default definition of my_class::operator= does apply the lvalue-to-rvalue conversion to x.m.
Therefore, the most important part to me seems to be
Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
So typically, an lvalue-to-rvalue conversion will just read the value from an object. It isn't just a no-op conversion between value (expression) categories; it can even create a temporary by calling a copy constructor. And the lvalue-to-rvalue conversion always returns a prvalue value, not a (temporary) object.
Note that the lvalue-to-rvalue conversion is not the only conversion that converts an lvalue to a prvalue: There's also the array-to-pointer conversion and the function-to-pointer conversion.
values and expressions
Most expressions don't yield objects[[citation needed]]. However, an id-expression can be an identifier, which denotes an entity. An object is an entity, so there are expressions which yield objects:
int x;
x = 5;
The left hand side of the assignment-expression x = 5 also needs to be an expression. x here is an id-expression, because x is an identifier. The result of this id-expression is the object denoted by x.
Expressions apply implicit conversions: [expr]/9
Whenever a glvalue expression appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue, array-to-pointer, or function-to-pointer standard conversions are applied to convert the expression to a prvalue.
And /10 about usual arithmetic conversions as well as /3 about user-defined conversions.
I'd love now to quote an operator that "expects a prvalue for that operand", but cannot find any but casts. For example, [expr.dynamic.cast]/2 "If T is a pointer type, v [the operand] shall be a prvalue of a pointer to complete class type".
The usual arithmetic conversions required by many arithmetic operators do invoke an lvalue-to-rvalue conversion indirectly via the standard conversion used. All standard conversions but the three that convert from lvalues to rvalues expect prvalues.
The simple assignment however doesn't invoke the usual arithmetic conversions. It is defined in [expr.ass]/2 as:
In simple assignment (=), the value of the expression replaces that of the object referred to by the left operand.
So although it doesn't explicitly require a prvalue expression on the right hand side, it does require a value. It is not clear to me if this strictly requires the lvalue-to-rvalue conversion. There's an argument that accessing the value of an uninitialized variable should always invoke undefined behaviour (also see CWG 616), no matter if it's by assigning its value to an object or by adding its value to another value. But this undefined behaviour is only required for an lvalue-to-rvalue conversion (AFAIK), which then should be the only way to access the value stored in an object.
If this more conceptual view is valid, that we need the lvalue-to-rvalue conversion to access the value inside an object, then it'd be much easier to understand where it is (and needs to be) applied.
Initialization
As with simple assignment, there's a discussion whether or not the lvalue-to-rvalue conversion is required to initialize another object:
int x = 42; // initializer is a non-string literal -> prvalue
int y = x; // initializer is an object / lvalue
For fundamental types, [dcl.init]/17 last bullet point says:
Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. Standard conversions will be used, if necessary, to convert the initializer expression to the cv-unqualified version of the destination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed.
However, it also mentioned the value of the initializer expression. Similar to the simple-assignment-expression, we can take this as an indirect invocation of the lvalue-to-rvalue conversion.
Reference binding
If we see lvalue-to-rvalue conversion as a way to access the value of an object (plus the creation of a temporary for class type operands), we understand that it's not applied generally for binding to a reference: A reference is an lvalue, it always refers to an object. So if we bound values to references, we'd need to create temporary objects holding those values. And this is indeed the case if the initializer-expression of a reference is a prvalue (which is a value or a temporary object):
int const& lr = 42; // create a temporary object, bind it to `r`
int&& rv = 42; // same
Binding a prvalue to an lvalue reference is prohibited, but prvalues of class types with conversion functions that yield lvalue references may be bound to lvalue references of the converted type.
The complete description of reference binding in [dcl.init.ref] is rather long and rather off-topic. I think the essence of it relating to this question is that references refer to objects, therefore no glvalue-to-prvalue (object-to-value) conversion.

On glvalues: A glvalue ("generalized" lvalue) is an expression that is either an lvalue or an xvalue.
A glvalue may be implicitly converted to prvalue with lvalue-to-rvalue, array-to-pointer, or function-to-pointer implicit conversion.
Lvalue transformations are applied when lvalue argument (e.g. reference to an object) is used in context where rvalue (e.g. a number) is expected.
Lvalue to rvalue conversion
A glvalue of any non-function, non-array type T can be implicitly converted to prvalue of the same type. If T is a non-class type, this conversion also removes cv-qualifiers. Unless encountered in unevaluated context (in an operand of sizeof, typeid, noexcept, or decltype), this conversion effectively copy-constructs a temporary object of type T using the original glvalue as the constructor argument, and that temporary object is returned as a prvalue. If the glvalue has the type std::nullptr_t, the resulting prvalue is the null pointer constant nullptr.