进程引用初始化时是clang中的错误吗

Question

#include <iostream>
struct B;
struct A{
  operator B&&() const;
};
struct B{
  B(A const&){

  }
  B() {}
};
int main(){
    A a;
    B&& rf = a;  //#1
}

B g;
A::operator B&&() const {  
    std::cout<<"execute\n";
    return std::move(g);
}

考虑上面的代码，结果在这里。#1处的引用绑定受以下规则约束：

否则，该引用应为对非易失常数类型的左值引用（即cv1应为常数），或该引用应为右值引用。

• 如果初始化表达式

• 是右值（但不是位字段）或函数左值，并且"cv1 T1"与"cv2 T2"引用兼容，或
• 具有类类型（即T2是类类型），其中T1与T2不相关，并且可以转换为右值或函数左值类型cv3 T3，其中cv1 T1与cv3 T3引用兼容（参见[over.match.ref]），

然后，第一种情况下初始值设定项表达式的值和第二种情况下转换的结果被称为转换后的初始值设定项。如果转换的初始值设定项是prvalue，则将其类型T4调整为类型“cv1 T4”（[conv.qual]），并应用临时物化转换。在任何情况下，引用都会绑定到生成的glvalue（或相应的基类子对象）。

• 否则：

• 如果T1或T2是一个类类型，而T1与T2没有引用关系，则通过用户定义的转换（[dcl.init]，[over.match.copy]，[over.match.conv]），可以使用“cv1 T1”类型的对象的复制初始化规则来考虑用户定义的转换；如果相应的非引用副本初始化格式不正确，则程序格式不正确。然后，调用转换函数的结果（如非引用副本初始化所述）用于直接初始化引用。对于这种直接初始化，不考虑用户定义的转换

根据上述规则的结构，If分支的第二个项目符号对于B就足够了

GCC的结果证明了这些规则所说的，但是Clang抱怨执行引用绑定的转换函数不明确（Clang似乎将各自分支中的两个转换函数都视为候选函数）。是叮当作响的虫子吗？

尽管如此

#include <iostream>
struct B;
struct A{
  operator B&&() const;
};
struct B{
  B(A&){

  }
  B() {}
};
int main(){
    A a;
    B&& rf = a;  //#1
}

B g;
A::operator B&&() const {  
    std::cout<<"execute\n";
    return std::move(g);
}

操作员B仍然同意GCC




Answer 1

是的，你选对段落[dcl.init.ref]§5.2.1.2：

否则，该引用应为对非易失常数类型的左值引用（即cv1应为常数），或该引用应为右值引用。

• 如果初始值设定项表达式

• 是右值[...]
• 具有类类型（即T2是类类型），其中T1与T2不相关，并且可以转换为右值或函数左值类型cv3 T3，其中cv1 T1与cv3 T3引用兼容（参见[over.match.ref]），

引用初始化的目的是首先尝试直接绑定（定义在[dcl.init.ref]一节的最后一个规范性语句中，简而言之：当初始值设定项和引用是引用相关的，或者如果有一个转换函数的结果类型是与初始化引用相关的引用时，就会发生直接绑定）。这是一个叮当作响的bug，在标准中肯定不是一个公开的问题。

（可能引起怀疑的站点公开问题（CWG2028）与某些“直接绑定”可能涉及临时物化的事实有关，因此这些情况不应是直接引用绑定，而应是对用户定义转换结果的间接绑定。）