为什么选择转换运算符的这种重载？

Question

考虑following code。

struct any
{
    template <typename T>
    operator T &&() const;

    template <typename T>
    operator T &() const;
};
int main()
{
    int a = any{};
}

这里的第二个转换运算符是由重载决议选择的。为什么？

据我了解，这两个运算符分别推导出为operator int &&() const和operator int &() const。两者都在一组可行的功能中。通读 [over.match.best] 并没有帮助我弄清楚为什么后者更好。

为什么后者的功能比前者好？

Answer 1

首选返回T& 的转换运算符，因为它比返回T&& 的转换运算符更专业。

参见 C++17 [temp.deduct.partial]/(3.2)：

在调用转换函数的上下文中，使用转换函数模板的返回类型。

和/9：

如果对于给定类型，双向推导成功（即，在上述转换后类型相同）并且P 和A 都是引用类型（在被上述类型替换之前） : — 如果参数模板中的类型是左值引用，而参数模板中的类型不是，则认为参数类型至少与参数一样特化 类型; ...

Answer 2

推导的返回值转换运算符有点奇怪。但核心思想是，它就像一个函数参数来选择使用哪一个。

当在T&& 和T& 之间做出决定时，T& 在重载解决规则中获胜。这是为了允许：

template<class T>
void f( T&& ) { std::cout << "rvalue"; }
template<class T>
void f( T& ) { std::cout << "lvalue"; }

工作。 T&& 可以匹配左值，但是当左值和通用引用重载都可用时，首选左值。

正确的转换运算符集可能是：

template <typename T>
operator T&&() &&;

template <typename T>
operator T &() const; // maybe &

甚至

template <typename T>
operator T() &&;

template <typename T>
operator T &() const; // maybe &

为了防止失败的延长寿命咬你。

3 用于确定排序的类型取决于完成部分排序的上下文：

[剪辑]

(3.2) 在调用转换函数的上下文中，使用转换函数模板的返回类型。

然后在选择重载时取决于“更专业”的规则：

(9.1) 如果参数模板中的类型是左值引用，而参数模板中的类型不是，则认为参数类型至少与参数类型一样特化；否则，

因此operator T&& 至少不如operator T& 专业化，同时没有规则状态operator T& 至少不如operator T&& 专业化，所以operator T& 比operator T&& 更专业化。

在其他条件相同的情况下，更专业的模板胜过更少的重载解决方案。

Answer 3

我们正在尝试从 any 初始化 int。它的过程：

1. 找出我们可以做到的所有方法。也就是说，确定我们所有的候选人。这些来自非显式转换函数，可以通过标准转换序列 ([over.match.conv]) 转换为 int。该部分包含以下短语：

   对返回“对X 的引用”的转换函数的调用是X 类型的glvalue，因此在选择候选函数的过程中，这种转换函数被认为产生X。

2. 选择最佳候选人。

在第 1 步之后，我们有两个候选人。 operator int&() const 和 operator int&&() const，为了选择候选函数，两者都被认为产生 int。哪个是产生int 的最佳 候选人？

我们确实有一个决胜局，它更喜欢左值引用而不是右值引用 ([over.ics.rank]/3.2.3)。但是，我们并没有真正在此处绑定引用，并且示例有些颠倒 - 这是针对参数是左值与右值引用的情况。

如果这不适用，那么我们将通过[over.match.best]/2.5 决胜局来选择更专业的函数模板。

一般来说，经验法则是更具体的转换是最佳匹配。左值引用转换函数比转发引用转换函数更具体，所以首选。我们正在初始化的 int 没有什么需要右值（如果我们改为初始化 int&&，那么 operator T&() const 就不会是候选对象）。