What does "bind directly" mean in reference initialization? - c++

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).

Related

List initialization of a reference: is GCC or Clang correct?

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}.

Why is this reference binding ill-formed?

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.

Where exactly in the C++14 Standard does it allow the use of a user-defined conversion function in a direct-initialization?

For example, in the snippet below the user-defined conversion function C::operator A() is implicitly invoked to convert an lvalue of type C into a prvalue of type A, which copy-initializes the variable a in a direct-initialization.
struct A {};
struct C { operator A() { return A(); }; };
int main()
{
C c;
A a(c);
}
I just want to know where this is described in the C++14 Standard. I have a feeling that the answer is in [over.match.copy]/1 bullet point (1.2), but I'm having a problem with the section title Copy-initialization by user-defined conversion.
There are two constructors on A that can be invoked with a single argument:
A(A const&); // copy constructor
A(A&& ); // move constructor
In either case, [dcl.init.ref] explains how we can initialize the reference:
A reference of type "cv1 T1" is initialized by an expression of type "cv2 T2" as follows:
— 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).
We have references of type A or A const being initialized by an expression of type C, which is a class type not reference-related to A. To check if it can be converted to a reference-compatible type cv3 T3, we check [over.match.ref]:
The conversion functions of S and its base classes are considered. Those non-explicit conversion functions that are not hidden within S and yield type “lvalue reference to cv2 T2” (when initializing an lvalue reference or an rvalue reference to function) or “cv2 T2” or “rvalue reference to cv2 T2” (when initializing an rvalue reference or an lvalue reference to function), where “cv1 T” is reference-compatible with “cv2 T2”, are candidate functions. For direct-initialization, [...]
Hence, for the copy constructor, we consider those conversion functions that yield A& and for the move constructor, we consider those conversion functions that yield A or A&&. We don't have the former, but we do have the latter: operator A().
This makes the move constructor of A a viable constructor, but not the copy constructor of A. Since we only have one viable candidate, it is trivially the best viable candidate.

Implicit conversion to lvalue reference

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.

(GCC bug?) Implicit conversion to a derived class

I've encountered a problem with implicit conversion in C++. The following is a minimal example:
struct A {
virtual void f()=0; // abstract
};
struct Ad : A {
virtual void f() {} // not abstract
};
struct B {
operator Ad () const { return Ad(); }
};
void test(A const &lhs) {}
int main()
{
B b;
test(b);
}
What I would like the compiler to do is: convert b to a variable of type Ad (using the conversion defined in B) and pass the result to test. However, the above code does not compile in GCC (with C++11 enabled), the result being Cannot allocate an object of abstract type 'A'.
Some things to note:
Clang compiles this.
If you make A non-abstract by changing f()=0; to f() {}, the code works just fine.
The compiler does find the conversion operator (as indicated by 2), but it doesn't do what I'd like it to do.
(All quotes from N4140, the C++14 FD)
TL;DR: The code is well-formed, this is (or was) a GCC bug.
The rules for reference initialization are covered in [dcl.init.ref]/5. I'll first show you the bullet that doesn't cover it - if you want to skip that go straight to the third quote.
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.
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
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).
And reference-compability is defined in [dcl.init.ref]/41.
Now consider the linked 13.3.1.6:
Under the conditions specified in 8.5.3, a reference can be bound
directly to a glvalue or class prvalue that is the result of applying
a conversion function to an initializer expression. Overload
resolution is used to select the conversion function to be invoked.
Assuming that “cv1 T” is the underlying 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:
The conversion functions of S and its base classes are considered. Those non-explicit conversion functions that are not
hidden within S and yield type “lvalue reference to cv2 T2”
(when initializing an lvalue reference or an rvalue reference to
function) or “cv2 T2” [..],
where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”,
are candidate functions. For direct-initialization, [..].
As you can see, your conversion function isn't a candidate after this paragraph. Thus the next bullet in [dcl.init]/5 is applicable:
Otherwise:
If T1 is a class type, user-defined conversions are considered using the rules for copy-initialization of an object of type “cv1
T1” by user-defined conversion (8.5, 13.3.1.4); 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. The program is
ill-formed if the direct-initialization does not result in a direct
binding or if it involves a user-defined conversion.
Note that the phrase "the program is
ill-formed if the corresponding non-reference copy-initialization
would be ill-formed" may imply that as
B b;
A a = b;
is ill-formed, the program is ill-formed. I believe this to be a defect or vagueness in the wording though, and not the reason that GCC does not accept the code. Assuredly the wording solely aims at the initialization itself, not the fact that a most-derived object of type T1 (aka A) can be created in the first place.
Finally 13.3.1.4 accepts our conversion function:
Assuming that “cv1 T” is the type of the object being initialized,
with T a class type, the candidate functions are selected as
follows:
The converting constructors (12.3.1) of T are candidate functions.
When the type of the initializer expression is a class type “cv S”, the non-explicit conversion functions of S and its base
classes are considered. [..]. Those that are not hidden within S
and yield a type whose cv-unqualified version is the same type as
T or is a derived class thereof are candidate functions.
Now the last question is whether in
A const& ref(Ad());
ref is bound directly. And it is.
Thus the original parameter reference binds directly, and no most-derived object of type A must be created.
What GCC presumably thinks is that a temporary of type A must be initialized and the reference be bound to that temporary. Or it pedantically follows the above defected wording, which is very unlikely.
1)
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 and cv1 is the same cv-qualification as, or
greater cv-qualification than, cv2.