CWG2985 [dcl.init.ref] Direct-initialization of a reference after conversion

[ranaanoop]

Full name of submitter: Anoop Rana

Reference (section label): [dcl.init.ref]

Link to reflector thread (if any): https://stackoverflow.com/questions/78867403/reference-initialization-using-list-initialization-accepted-by-gcc-and-msvc-but

Issue description:

There are two main issues described here. First is that dcl.init.ref#5.4.1.sentence-2 doesn't specify if the reference is direct initialized using () or using {}. This matters because X&& ref{z}; form is accepted by three compilers while X&& r = z; is rejected by all. The second issue is that we should make X&& r =z; and X&&{z}; be more consistent and ill-formed.
So to make the issue clearer, consider the following example: Demo

struct X
{
    public:
    X(){}
};
struct Y : X 
{
    
};
struct Z
{
    public:
        operator const Y () const
        {
            return {};
        }
};
int main()
{
    Z z;
    // X&& r = z; // #1: All four rejects this
    X&& ref{z}; //#2:   Clang: Nope, gcc: Ok, msvc: Ok, Edg: Ok
}

First we see how/why #1 is almost ill-formed as per the current wording. I say "almost" because [dcl.init.ref#5.4.1] doesn't specify if () or {} form is used for the direct initialization. And this might make a difference as already seen from X&& ref{z}; which is accepted by 3 compilers but not clang.

So to understand #1 we go to dcl.init.ref:

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

• [...]
• [...]
• [...]
• Otherwise, T1 shall not be reference-related to T2.
  • If T1 or T2 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 ([dcl.init], [over.match.copy], [over.match.conv]); 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.

This means that the result of the conversion function which will be of type const Y will be used to direct initialize r.

So the initialization process will be repeated again. This time we first go to direct initialization:

If the destination type is a reference type, see [dcl.init.ref].

So now come to dcl.init.ref and see that none of the bullet points is applicable for initialization of the reference r from const Y.

In particular, 5.1 is not applicable because the reference is not lvalue reference.

Similarly 5.2 is not applicable.

5.3 is also not applicable.

5.4 is not applicable because const Y is reference related to X as X is a base.

So none of the bullet points are applicable for the direct initialization of r by const Y and so X&& r = z; is ill-formed.

The important thing here is that here we didn't go to dcl.init#general-16.1 but instead to dcl.init#general-16.2. But the dcl.init.ref#5.4.1.sentence-2 currently doesn't specify that {} form of direct initialization is not used.

We can solve this first issue by changing "direct initialization" to "direct-non-list-initialization" or directly saying () form is used instead of {}.

Additionally, there might also be another issue(that of consistency) between not allowing X&& r = z; but allowing X&& ref{z};. That should also be fixed(if any) by additional wording changes(apart from what is suggested here).

Suggested Resolution

Change dcl.init.ref#5.4.1.sentence-2 to as highlighted below in bold:

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 using direct-non-list-initialization. For this direct-initialization, user-defined conversions are not considered.

[t3nsor]

I retracted my previous comment.

I don't know if we want to set a precedent of saying "direct-non-list-initialization" everywhere we mean that, because there are probably other places that would need to be changed. Instead maybe we should say somewhere that to direct-initialize an object or reference from an expression E means to initialize it as if its initializer were ( E ).

[t3nsor]

For this particular example, I don't know if it matters whether direct-list-initialization is used to initialize the reference in the last step. If you used direct-list-initialization, you would fall through to [dcl.init.list]/3.9 which just tells you to use direct-initialization anyway.

[t3nsor]

How about in this example:

struct S {
    operator double();
};
int&& r{S()};

Here, the choice of whether to use list-initialization for the last step affects whether it's well-formed, because the conversion from double to int would be narrowing in a list-initialization context.

EDG and GCC accept it. Clang and MSVC reject.

[jensmaurer]

This example very much looks like a narrowing situation to me. It should be ill-formed.

[ranaanoop]

@jensmaurer Are you referring to #1 or #2 or both. I think both should be ill-formed. Note that to clarify that #1 is ill-formed we will need to specify which form of direct initialization(( ) or { }) is used even though they might both eventually lead to the same conclusion. The second issue is that the #2 should also be ill-formed(as you said, assuming you were referring to #2) but it is not clear if #2 is ill-formed.

[ranaanoop]

@t3nsor Yes, the other option/alternative is to specify directly the (E) form of direct initialization as mentioned in the original issue without the E.

[jensmaurer]

I'm referring to @t3nsor's latest example:

struct S {
    operator double();
};
int&& r{S()};

[ranaanoop]

@jensmaurer Yes, that is why I included it in the new issue. I agree that it should also be ill-formed.

[jensmaurer]

What does the current wording say about #2 ? Is that well-formed?

[ranaanoop]

@jensmaurer #2 which is (X&& ref{z};) seems to be well-formed as explained below.

First X&& r{z}; is list-initialization. So we reach dcl.init.list#3:

List-initialization of an object or reference of type cv T is defined as follows:

• [..]
• [...]
• Otherwise, if T is a reference type, a prvalue is generated. The prvalue initializes its result object by copy-list-initialization from the initializer list. The prvalue is then used to direct-initialize the reference.
  The type of the prvalue is the type referenced by T, unless T is “reference to array of unknown bound of U”, in which case the type of the prvalue is the type of x in the declaration U x[] H, where H is the initializer list.

So first we need to check if the copy-list-initialization of the result object from the initializer list {z}. Basically, we need to check the validity of X resultObject = {z}; to move further.

So we go to dcl.init#general-16:

The semantics of initializers are as follows.
The destination type is the cv-unqualified type of the object or reference being initialized and the source type is the type of the initializer expression.
If the initializer is not a single (possibly parenthesized) expression, the source type is not defined.

• If the initializer is a (non-parenthesized) braced-init-list or is = braced-init-list, the object or reference is list-initialized ([dcl.init.list]).

So we again move to dcl.init.list, this time to check the validity of X resultObject = {z};:

List-initialization of an object or reference of type cv T is defined as follows:

• [...]
• [...]
• Otherwise, if T is a class type, constructors are considered.
  The applicable constructors are enumerated and the best one is chosen through overload resolution ([over.match], [over.match.list]).
  If a narrowing conversion (see below) is required to convert any of the arguments, the program is ill-formed.

This means that X's constructors(including the implicit copy ctor etc) will be enumerated for the argument z. Now we move to over.match:

Overload resolution selects the function to call in seven distinct contexts within the language:

• [...]
• [...]
• invocation of a user-defined conversion for copy-initialization of a class object ([over.match.copy]);

Now, we go to over.match#copy:

Under the conditions specified in [dcl.init], as part of a copy-initialization of an object of class type, a user-defined conversion can be invoked to convert an initializer expression to the type of the object being initialized. Overload resolution is used to select the user-defined conversion to be invoked.

Assuming that “cv1 T” is the type of the object being initialized, with T a class type, the candidate functions are selected as follows:

• [...]
• When the type of the initializer expression is a class type “cv S”, conversion functions are considered. The permissible types for non-explicit conversion functions are T and any class derived from T.
  When initializing a temporary object ([class.mem]) to be bound to the first parameter of a constructor where the parameter is of type “reference to cv2 T” and the constructor is called with a single argument in the context of direct-initialization of an object of type “cv3 T”, the permissible types for explicit conversion functions are the same; otherwise there are none.

In both cases, the argument list has one argument, which is the initializer expression.

This means that the conversion function Y::operator const Y () const can be used to convert the initializer expression z to an rvalue which will then be used as argument for one of X's ctors.

The important thing is that only the implicit copy ctor X::X(const X&&) is viable here for the rvalue obtained as a resut of the conversion function.The implicit move ctor X::X(X&&) is not viable because it's parameter is a non-const rvalue reference.

---

Note that if you change the move ctor's parameter to be const X&&(demo), then both the copy ctor and the move ctor will be viable for the rvalue obtaied from the conversion operator but then move ctor X::X(const X&&) will be a better match than the copy ctor X::X(const X&) because the argument(result of conversion operator) is a rvalue.

[jensmaurer]

The cross-reference in dcl.init.list points to [over.match.list], so I'd go there, not to over.match.copy.

[ranaanoop]

@jensmaurer We would've to take both [over.match] as well as [over.match.list] into account as dcl.init#list-3.7(which was applied here), cross references both of them(over.match and over.match.list). Btw I only omitted writing [over.match.list] explicitly in my previous comment as even after [over.match.list] we'd still have to take [over.match] into account.

[jensmaurer]

The list you quoted from [over.match] is introductory fluff; it should never be used to select a subclause of [over.match]. Again, please use [over.match.list] in your analysis, because that's what the normative intent is. We always use the rules for list-initialization overload resolution when an initializer list is involved.