The following quotes are needed in the question:
[dcl.init.ref]/5:
5- A reference to type “cv1 T1” is initialized by an expression of
type “cv2 T2” as follows:
(5.1) [..]
(5.2) [..]
(5.3) Otherwise, if the initializer expression
(5.3.1) is an rvalue (but not a bit-field) or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or
(5.3.2) [..]
then the value of the initializer expression in the first case and the result of the conversion in the second case is called the converted initializer. If the converted initializer is a prvalue, its type T4 is adjusted to type “cv1 T4” ([conv.qual]) and the temporary materialization conversion ([conv.rval]) is applied. In any case, the reference is bound to the resulting glvalue (or to an appropriate base class subobject).
(emphasis mine)
[expr.type]/2:
If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis.
Consider the following example:
const int&& r1 = 0;
Taking cv1 T1 as const int, and cv2 T2 as int
It's clear that bullet [dcl.init.ref]/(5.3.1) is applied here. The initializer expression is an rvalue (prvalue); and cv1 T1 (const int) is reference-compatible with cv2 T2 (int). And since that the converted initializer is prvalue, its type T4 (int) is adjusted to cv1 T4 (const int). Then, temporary materialization is applied.
But, per [expr.type]/2, before applying temporary materialization conversion, cv1 T4 (const int) becomes int again. Then, by applying temporary materialization, we've got an xvalue denoting an object of type int. Then the reference is bound to the resulting glvalue.
Here's my first question. The reference r1 is reference to const int and the resulting glvalue is an xvalue denoting an object of type int. So how r1, which is of type const int&&, is now binding to an xvalue of type int? Is this valid binding? Is any missing wording? Am I misunderstood/missed something?
Consider another last example:
const int&& r2 = static_cast<int&&>(0);
The same wording as above applies: The initializer expression is an rvalue (xvalue) and cv1 T1 (const int) is reference-compatible with cv2 T2 (int). And since that the converted initializer is an xvalue not prvalue, [conv.qual] or even [conv.rval] is not applied (i.e, the condition "If the converted initializer is a prvalue, ..") isn't satisfied.
I know that [conv.rval] isn't needed here since the initializer expression is already an xvalue, but [conv.qual] is required.
And that's my last question. The reference r2 is reference to const int and the resulting glvalue is an xvalue denoting an object of type int. So how r2, which is of type const int&&, is now binding to an xvalue of type int? Is this valid binding? Is any missing wording? Am I misunderstood/missed something?
Here's my first question. The reference r1 is reference to const int and the resulting glvalue is an xvalue denoting an object of type int. So how r1, which is of type const int&&, is now binding to an xvalue of type int? Is this valid binding?
Yes, that's what happens. I fail to see the issue here.
I know that [conv.rval] isn't needed here since the initializer expression is already an xvalue, but [conv.qual] is required.
No it isn't. Again, I fail to see the issue.
There is, in fact, no rule that says that a reference of type T&&, can only refer to an object whose type is exactly T. A const int&& can refer to an int object. The concept of reference-compatibility was invented in order to describe what types of objects a reference can refer to.
Related
This is a followup to my previous question, where the apparent consensus was that the change in treatment of cv-qualifications of prvalues was just a fairly minor and inconsequential change intended to solve some inconsistencies (e.g. functions returning prvalues and declared with cv-qualified return types).
However, I see another place in the standard that appears to rely on prvalues having cv-qualified types: initialization of const references with prvalues through temporary materialization conversion. The relevant wording can be found in multiple spots in 9.3.3/5
[...] If the converted initializer is a prvalue, its type T4 is adjusted to type “cv1 T4” ([conv.qual]) and the temporary materialization conversion ([conv.rval]) is applied [...]
[...] Otherwise, the initializer expression is implicitly converted to a prvalue of type “cv1 T1”. The temporary materialization conversion is applied and the reference is bound to the result.
The intent is obviously to make sure that when we get to the actual temporary materialization conversion
7.3.4 Temporary materialization conversion
1 A prvalue of type T can be converted to an xvalue of type T. This conversion initializes a temporary object ([class.temporary]) of type T from the prvalue by evaluating the prvalue with the temporary object as its result object, and produces an xvalue denoting the temporary object. [...]
the type T that it receives as input includes the required cv-qualifications.
But how does that cv-qualification survive the 7.2.2/2 in case of non-class non-array prvalue?
7.2.2 Type
2 If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis.
Or does it?
E.g. what kind of temporary do we get in this example
const int &r = 42;
Is the temporary const or not? Can we do
const_cast<int &>(r) = 101; // Undefined or not?
without triggering undefined behavior? If I'm not mistaken, the original intent was to obtain a const int temporary in such cases. Is it still true? (For class types the answer is clear - we get a const temporary.)
Why are you doubting the language of 7.2.2? This seems pretty unambiguous that cv qualifiers are discarded on non-class, non-array prvalues, so the type T in temporary materialization is a non-const, non-volatile type.
If that weren't the case, then you wouldn't be able to bind prvalues to non-const rvalue references. Yet it seems overwhelmingly likely that the standard was intended to accept programs such as this:
#include <type_traits>
template<typename T> void
f(T &&t)
{
static_assert(std::is_same_v<decltype(t), int&&>);
++t;
}
int
main()
{
f(5);
}
E.g. what kind of temporary do we get in this example const int &r = 42; Is the temporary const or not?
Let's analyze your example to see whether it's const or not. Given this example
const int &r = 42;
The applicable wording from the standard is [dcl.init.ref]/5
A reference to type “cv1 T1” is initialized by an expression of
type “cv2 T2” as follows:
(5.1) [..]
(5.2) [..]
(5.3) Otherwise, if the initializer expression
(5.3.1) is an rvalue (but not a bit-field) or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or
(5.3.2) [..]
then the value of the initializer expression in the first case and the result of the conversion in the second case is called the converted initializer. If the converted initializer is a prvalue, its type T4 is adjusted to type “cv1 T4” ([conv.qual]) and the temporary materialization conversion ([conv.rval]) is applied. In any case, the reference is bound to the resulting glvalue (or to an appropriate base class subobject).
It's already known that the initializer expression 42 is a prvalue, and const int (cv1 T1) is reference-compatible with int (cv2 T2). And the converted initializer here is of type int (T4); then it's adjusted, via [conv.qual], to const int (cv1 T4); then temporary materialization ([conv.rval]) gets applied. Note that, [expr.type]/2 doesn't apply here because the initial type of the prvalue is cv-unqualified type:
If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis.
Note also, it cannot be applied after adjustment to cv1 T4 because cv1 T4 is not the initial type of the prvalue.
So the adjusted prvalue has type const int (cv1 T4) Then, temporary materialization gets applied to this prvalue; [conv.rval]:
A prvalue of type T can be converted to an xvalue of type T. This conversion initializes a temporary object ([class.temporary]) of type T [..]
The const int prvalue gets converted to an xvalue of type const int. And a temporary of type const int gets initialized. So you have an xvalue denoting a temporary of type const int. And the reference r is bound to the resulting glvalue (i.e, r is binding to a xvalue denoting a temporary of type const int).
So as far as I can tell, the temporary that has been created is const-qualified.
Can we do const_cast<int &>(r) = 101; without triggering undefined behavior?
No, this undefined behavior by definition since you're trying to modify (write into) a read-only memory location:
[expr.const.cast]/6: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a const_cast that casts away a const-qualifier can produce undefined behavior.
[dcl.type.cv]/4: Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const
object during its lifetime (3.8) results in undefined behavior.
Given this example:
int g_i = 10;
struct S {
operator int&(){ return g_i; }
};
int main() {
S s;
int& iref1 = s; // implicit conversion
int& iref2 = {s}; // clang++ error, g++ compiles fine:
// `s` is converted
// to a temporary int and binds with
// lvalue reference
int&& iref3 = {s}; // clang++ compiles, g++ error:
// cannot bind rvalue reference
// to lvalue
}
The errors are as described in the comments.
gcc 8.2.1 and clang 7.0.1 were used and disagree about what is happening in this example. Could someone clarify this?
In list initialization :
Otherwise, if the initializer list has a single element of type E and either T is not a reference type or its referenced type is reference-related to E, the object or reference is initialized from that element (by copy-initialization for copy-list-initialization, or by direct-initialization for direct-list-initialization); if a narrowing conversion (see below) is required to convert the element to T, the program is ill-formed.
Otherwise, if T is a reference type, a prvalue of the type referenced by T is generated. The prvalue initializes its result object by copy-list-initialization or direct-list-initialization, depending on the kind of initialization for the reference. The prvalue is then used to direct-initialize the reference. [ Note: As usual, the binding will fail and the program is ill-formed if the reference type is an lvalue reference to a non-const type. — end note ]
In reference initialization:
Given types “cv1 T1” and “cv2 T2”, “cv1 T1” is reference-related to “cv2 T2” if T1 is the same type as T2, or T1 is a base class of T2. “cv1 T1” is reference-compatible with “cv2 T2” if
- T1 is reference-related to T2, or
- T2 is “noexcept function” and T1 is “function”, where the function types are otherwise the same,
...and later on there's some (personally ambiguous) language on user-defined conversions:
For example:
If the reference is an lvalue reference and the initializer expression
...
has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (this conversion is selected by enumerating the applicable conversion functions ([over.match.ref]) and choosing the best one through overload resolution),
...
then the reference is bound to the ... value result of the conversion
...
Otherwise, if the initializer expression
...
has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an rvalue or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3”
...
then the value of the ... result of the conversion in the second case is called the converted initializer. If the converted initializer is a prvalue, its type T4 is adjusted to type “cv1 T4”
...
Otherwise:
- If T1 or T2 is a class type and T1 is not reference-related to T2, user-defined conversions are considered using the rules for copy-initialization of an object of type “cv1 T1” by user-defined conversion ... The result of the call to the conversion function, as described for the non-reference copy-initialization, is then used to direct-initialize the reference. For this direct-initialization, user-defined conversions are not considered.
...
Otherwise, the initializer expression is implicitly converted to a prvalue of type “cv1 T1”. The temporary materialization conversion is applied and the reference is bound to the result.
These rules are quite nuanced and I cannot fully grasp each situation.
To me, it seems like a prvalue should be getting generated (I agree with clang), but the language on reference initialization, and interaction with list initialization is very fuzzy.
Let's read the standard in the correct order, so that we know which sections apply to the situation at hand.
[dcl.init]/17 says:
The semantics of initializers are as follows... If the initializer is a (non-parenthesized) braced-init-list or is = braced-init-list, the object or reference is list-initialized (11.6.4) ...
So we go to [dcl.init.list] (11.6.4). Paragraph 3 says:
List-initialization of an object or reference of type T is defined as follows: (... cases that don't apply are elided from this quotation...) Otherwise, if the initializer list has a single element of type E and either T is not a reference type or its referenced type is reference-related to E ... otherwise, if T is a reference type, a prvalue of the type referenced by T is generated. The prvalue
initializes its result object by copy-list-initialization or direct-list-initialization, depending on the kind of initialization for the reference. The prvalue is then used to direct-initialize the reference. [ Note: As
usual, the binding will fail and the program is ill-formed if the reference type is an lvalue reference to a
non-const type. —end note ]
According to [dcl.init.ref]/4:
Given types “cv1 T1” and “cv2 T2”, “cv1 T1” is reference-related to “cv2 T2” if T1 is the same type as T2, or T1 is a base class of T2.
Therefore, in your code, the referenced type int is not reference-related to the type in the initializer list, namely S. Thus, by [dcl.init.list]/3, a prvalue of type int is generated, and it takes the form int{s}. And as the note says, in the case of iref2, the program is ill-formed because it tries to bind a non-const lvalue reference to a prvalue. In the case of iref3, the program should compile since iref3 is being bound to the prvalue result int{s}.
Consider this code:
int **p = 0;
class S {
public:
explicit operator int**&() {
return p;
}
};
int main() {
S a;
int *const*&b (a); // error in both g++-7 and clang-5.0 with "-std=c++17"
return 0;
}
You will agree
a qualification conversion from int** to int*const* is possible, and
int *const*&b (a) is a direct-initialization.
First, we refer to 11.6.3, paragraph 5 [dcl.init.ref] from n4700.
A reference to type “cv1 T1 (= int*const*)” is initialized by an expression of type “cv2 T2 (= S)” as follows:
If the reference is an lvalue reference and the initializer expression
...
has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (this conversion is selected by enumerating the applicable conversion functions (16.3.1.6) and choosing the best one through overload resolution (16.3)),
then the reference is bound to the initializer expression lvalue in the first case and to the lvalue result of the conversion in the second case...
Here, we expect T3 to be int*const*. As noted above, whether it's a possible conversion is determined as per 16.3.1.6, paragraph 1 [over.match.ref].
... Assuming that “reference to cv1 T” is the type of the reference being
initialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functions are selected as follows:
... For direct-initialization, those explicit conversion functions that
are not hidden within S and yield type “lvalue reference to cv2 T2” or “cv2 T2” or “rvalue reference to cv2 T2”, respectively, where T2 is the same type as T or can be converted to type T with a qualification conversion are also candidate functions.
Here, S::operator int**& yields "lvalue reference to T2 (= int**)", and it can be converted to T (= int*const*) by a qualification conversion. Here, we can say that the conversion is possible, but the program is not accepted in both g++-7 and clang-5.0. Why is that?
The reference initialization rule we're looking for is [dcl.init.ref]:
A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:
We have cv1 T1 as int* const* and cv2 T2 as S. We then go through the next sections carefully:
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
has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (this conversion is selected by enumerating the applicable conversion functions ([over.match.ref]) and choosing the best one through overload resolution),
then the reference is bound to the initializer expression lvalue in the first case and to the lvalue result of the conversion in the second case (or, in either case, to the appropriate base class subobject of the object).
Our reference is an lvalue reference. The initializer expression is an lvalue but the two types are not reference-compatible, so the first bullet does not apply.
The initializer expression does have non-reference-related class type, but it cannot be converted to a reference-compatible type. The reference-compatible part is important. int** is not reference-compatible with int* const*, and while the former can be converted to the latter, the result would not be an lvalue - which is also required.
So, this section doesn't apply, and we move on.
Otherwise, the reference shall be an lvalue reference to a non-volatile const type (i.e., cv1 shall be const), or the reference shall be an rvalue reference.
Our reference meets neither of those criteria, so the initialization is ill-formed.
A simpler version of this failure would be:
int* pi;
int const*& r = pi; // error
We can't go through a qualification conversion when we have an lvalue reference to non-const type.
I'm looking at the standard 5.16 paragraph 3, trying to understand what is going on. Consider the type M defined as
struct M {
M();
M(const M&);
M(M&&);
};
If I have a ternary expression pred ? E1 : E2, where the type of E1 is const M& and the type of E2 is M&& does 5.16 paragraph 3 bullet 1 apply?
— If E2 is an lvalue: E1 can be converted to match E2 if E1 can be implicitly converted (Clause 4) to the
type “lvalue reference to T2”, subject to the constraint that in the conversion the reference must bind
directly (8.5.3) to an lvalue.
I think it doesn't, because to have an implicit conversion to const M&, which requires M to have the member function operator const M&().
However, I'm not sure, because it could be converted to const M implicitly, can the reference be implicitly added?
If it is implicitly convertible, does M&& bind directly to const M&?
I went through the procedure in 8.5.3, and I think that paragraph 5 bullet 2 is where this case falls, so it does bind directly, but I'm not certain.
— If the initializer expression [..] has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be
implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where
“cv1 T1” is reference-compatible with “cv3 T3”
You don't have expressions of type M&&, instead it would be adjusted to be an xvalue of type M.
So the question is: if you have an xvalue of type M, can it be implicitly converted to lvalue reference to const M? The answer is yes, since a const lvalue reference can be initialized with an rvalue. Such a reference binding is direct since it falls under the following case:
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”, ...
rather than the last case that involves construction of a temporary, which is the indirect binding case.
Therefore this use of the conditional operator will be well-formed. The xvalue of type M will be converted to an lvalue of type const M. Then the lvalue-to-rvalue conversion will be applied and the result will be a prvalue of type const M.
N4527 8.5.3 [dcl.init.ref]
5 A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:
(5.1) — [...]
(5.1.1) — [...]
(5.1.2) — [...]
(5.2) — Otherwise, the reference shall be an lvalue reference to a non-volatile const type (i.e., cv1 shall be
const), or the reference shall be 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 “cv1 T1”
is reference-compatible with “cv2 T2”, or
(5.2.1.2) — has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be
converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where “cv1 T1” is
reference-compatible with “cv3 T3” (see 13.3.1.6),
then the reference is bound to the value of the initializer expression in the first case and to
the result of the conversion in the second case (or, in either case, to an appropriate base class
subobject).
(5.2.2) — Otherwise:
(5.2.2.1) — If T1 or T2 is a class type and T1 is not reference-related to T2, user-defined conversions
are considered using the rules for copy-initialization of an object of type “cv1 T1” by userdefined
conversion (8.5, 13.3.1.4, 13.3.1.5); the program is ill-formed if the corresponding non-reference copy-initialization would be ill-formed. The result of the call to the conversion
function, as described for the non-reference copy-initialization, is then used to direct-initialize
the reference. For this direct-initialization, user-defined conversions are not considered.
(5.2.2.2) — Otherwise, a temporary of type “cv1 T1” is created and copy-initialized (8.5) from the initializer
expression. The reference is then bound to the temporary.
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.
In all cases except the last (i.e., creating and initializing a temporary from the initializer expression), the
reference is said to bind directly to the initializer expression.
What does the "last case" mean? 5.2.2(includes 5.2.2.1 and 5.2.2.2) or 5.2.2.2(just one)?
In other words, is 5.2.2.1 binding directly?
//case 5.2.1.2
struct X{};
struct Y{Y(X);};
const Y& y = X(); // bind directly
struct Z{operator X();};
const X& x = Z(); // bind directly
//case 5.2.2.1
struct A{operator int();};
const int& a = A(); // bind directly or not?
struct B{B(int);};
const B& b = 1; // bind directly or not?
The "last case" is referring to 5.2.2.2:
— Otherwise, a temporary of type “cv1 T1” is created and copy-initialized (8.5) from the initializer expression. The reference is then bound to the temporary.
This case is contingent on the previous condition being false, which is 5.2.2.1:
— If T1 or T2 is a class type and T1 is not reference-related to T2...
This isn't the case for the last two snippets of your example since in the first one A is of class type and int is not reference-related to A. In the second example, B is of class type and B is not reference-related to int. Since these are false 5.2.2.2 doesn't apply (they do bind directly).