clang失败，但g成功使用强制转换来赋值中的const无关类型运算符

Question

这里有一个简短的示例，它用lemon表示clang，但对编译器行为中的g差异有效，从而再现了这种“不可行的转换”。

#include <iostream>

struct A { 
    int i; 
};

#ifndef UNSCREW_CLANG
using cast_type = const A;
#else 
using cast_type = A;
#endif

struct B {
    operator cast_type () const {
        return A{i};
    }
    int i;
}; 

int main () { 
    A a{0};
    B b{1};

#ifndef CLANG_WORKAROUND
    a = b;
#else    
    a = b.operator cast_type ();
#endif    

    std::cout << a.i << std::endl;    

    return EXIT_SUCCESS;
}

住在戈博尔特家

g（4.9,5.2）默默编译；而clang（3.5,3.7）编译它

如果

using cast_type = A;

或

using cast_type = const A;
// [...] 
a = b.operator cast_type ();

使用，但不与默认

using cast_type = const A;
// [...] 
a = b; 

在这种情况下，clang（3.5）责备a=b：

testling.c++:25:9: error: no viable conversion from 'B' to 'A'
    a = b;
        ^
testling.c++:3:8: note: candidate constructor (the implicit copy constructor) 
not viable:
      no known conversion from 'B' to 'const A &' for 1st argument
struct A { 
       ^
testling.c++:3:8: note: candidate constructor (the implicit move constructor) 
not viable:
      no known conversion from 'B' to 'A &&' for 1st argument
struct A { 
       ^
testling.c++:14:5: note: candidate function
    operator cast_type () const {
    ^
testling.c++:3:8: note: passing argument to parameter here
struct A { 

关于2011¹标准：clang拒绝默认代码是正确的还是接受它是正确的？

注：这不是关于cast\u类型上的const限定符是否有意义的问题。这是关于哪个编译器的工作符合标准，并且仅限于此。

¹2014年在这里不应该有什么不同。

编辑：

请不要用通用c标记重新标记。首先，我想知道哪些行为符合2011年的标准，并保持委员会的敬业精神，不破坏现有标准(

Answer 1

所以看起来这被这个clang bug报告覆盖了右值重载隐藏了const左值？它有以下示例：

struct A{};
struct B{operator const A()const;};
void f(A const&);
#ifdef ERR
void f(A&&);
#endif
int main(){
  B a;
  f(a);
}

它失败了，错误与OP的代码相同。理查德·史密斯最后说：

更新：我们选择“f（A）”是正确的

  struct A {};
  struct B { operator const A(); } b;
  A &&a = b;

这里，[dcl.init.ref]p5 bullet 2 bullet 1 bullet 2不适用，因为[over.match.ref]p1找不到候选转换函数，因为“A”与“const A”不兼容引用。因此我们进入[dcl.init.ref]p5 bullet 2 bullet 2，从“b”复制初始化a类型的临时文件，并将引用绑定到该临时文件。我不确定在这个过程中我们哪里出错了。

但是，由于1604年的缺陷报告，我们又提出了另一条评论：

DR1604更改了规则，以便

 A &&a = b;

现在是格式错误的。所以我们现在拒绝初始化是正确的。但这仍然是一个糟糕的答案；我再次刺激了CWG。我们可能应该丢弃f（A

因此，看起来clang在今天的标准语言基础上做了正确的事情，但它可能会改变，因为至少clang团队似乎不同意这是正确的结果。因此，这可能会导致缺陷报告，我们必须等到问题解决后才能得出最终结论。

更新

看起来缺陷报告2077是基于这个问题提交的。