模板偏序——为什么这里偏扣成功

Question

考虑以下简单（就模板问题而言）示例：

#include <iostream>

template <typename T>
struct identity;

template <>
struct identity<int> {
    using type = int;
};

template<typename T> void bar(T, T ) { std::cout << "a\n"; }
template<typename T> void bar(T, typename identity<T>::type) { std::cout << "b\n"; }

int main ()
{
    bar(0, 0);
}

clang 和 gcc 都在那里打印“a”。根据[temp.deduct.partial]和[temp.func.order]中的规则，要确定偏序，我们需要合成一些唯一的类型。所以我们有两次推演尝试：

+---+-------------------------------+-------------------------------------------+
|   | Parameters                    | Arguments                                 |
+---+-------------------------------+-------------------------------------------+
| a | T, typename identity<T>::type | UniqueA, UniqueA                          |
| b | T, T                          | UniqueB, typename identity<UniqueB>::type |
+---+-------------------------------+-------------------------------------------+

对于“b”的推导，根据Richard Corden's answer，表达式typename identity<UniqueB>::type被视为一个类型并且不被计算。也就是说，这将被合成为：

+---+-------------------------------+--------------------+
|   | Parameters                    | Arguments          |
+---+-------------------------------+--------------------+
| a | T, typename identity<T>::type | UniqueA, UniqueA   |
| b | T, T                          | UniqueB, UniqueB_2 |
+---+-------------------------------+--------------------+

很明显，对“b”的推论失败了。这是两种不同的类型，因此您无法将T 推断为两者。

但是，在我看来，A 的扣除应该失败。对于第一个参数，您将匹配 T == UniqueA。第二个参数是一个非推导的上下文——所以如果UniqueA 可以转换为identity<UniqueA>::type，那么推导不会成功吗？后者是替换失败，所以我看不出这个推论怎么会成功。

gcc 和 clang 在这种情况下如何以及为什么更喜欢“a”重载？

Answer 1

正如 cmets 中所讨论的，我相信函数模板偏序算法的几个方面在标准中不清楚或根本没有指定，这在您的示例中显示。

为了让事情变得更有趣，MSVC（我测试了 12 和 14）拒绝了这个不明确的调用。我认为标准中没有任何内容可以最终证明哪个编译器是正确的，但我想我可能知道差异来自哪里；下面有一个说明。

您的问题（和this one）促使我对事情的运作方式进行更多调查。我决定写这个答案不是因为我认为它具有权威性，而是为了整理我在一个地方找到的信息（它不适合 cmets）。希望对你有用。

---

首先，issue 1391 的建议解决方案。我们在 cmets 和 chat 中广泛讨论了它。我认为，虽然它确实提供了一些澄清，但它也引入了一些问题。它将 [14.8.2.4p4] 更改为（新文本以粗体显示）：

上面从参数模板和 参数模板中的相应类型用作 P 和 A。 如果特定的 P 不包含 模板参数 参与模板参数推导，即P不习惯 确定顺序。

我认为这不是一个好主意，原因如下：

• 如果P是非依赖的，它根本不包含任何模板参数，所以它也不包含任何参与参数推导的参数，这将使粗体声明适用于它。但是，这会使template<class T> f(T, int) 和template<class T, class U> f(T, U) 无序，这是没有意义的。这可以说是对措辞的解释问题，但可能会引起混淆。
• 它与 用于确定排序 的概念相混淆，这会影响 [14.8.2.4p11]。这使得template<class T> void f(T) 和template<class T> void f(typename A<T>::a) 无序（从第一个到第二个推演成功，因为T 没有用于根据新规则进行部分排序的类型，所以它可以保持没有值）。目前，我测试过的所有编译器都报告说第二个更专业。

• 这将使#2 在以下示例中比#1 更专业：

  #include <iostream>
  
  template<class T> struct A { using a = T; };
  
  struct D { };
  template<class T> struct B { B() = default; B(D) { } };
  template<class T> struct C { C() = default; C(D) { } };
  
  template<class T> void f(T, B<T>) { std::cout << "#1\n"; } // #1
  template<class T> void f(T, C<typename A<T>::a>) { std::cout << "#2\n"; } // #2
  
  int main()
  {
     f<int>(1, D());
  }
  

  （#2 的第二个参数不用于偏序，所以从#1 到#2 的推导成功，反之则不行）。目前，这种说法是模棱两可的，可以说应该保持这种状态。

---

在查看了 Clang 的部分排序算法的实现之后，我认为可以更改标准文本以反映实际发生的情况。

保持 [p4] 不变，在 [p8] 和 [p9] 之间添加以下内容：

对于P / A 对：

• 如果P是非依赖的，当且仅当P和A是同一类型时才认为扣减成功。
• 不执行将推导的模板参数替换为出现在P 中的非推导上下文，并且不会影响推导过程的结果。
• 如果P 的所有模板参数的模板参数值都成功推导出来，除了只出现在非推导上下文中的那些，那么推导被认为是成功的（即使P 中使用的某些参数仍然没有值该特定P / A 对的扣除过程结束）。

注意事项：

• 关于第二个要点：[14.8.2.5p1] 讨论了查找模板参数值这将使P，在替换推导值之后（称为推导的A），与@ 兼容987654355@。这可能会导致混淆部分排序期间实际发生的情况；没有替代品。
• MSVC 在某些情况下似乎没有实现第三个要点。有关详细信息，请参阅下一节。
• 第二个和第三个要点还旨在涵盖P 具有A<T, typename U::b> 之类的形式的情况，这些情况不在issue 1391 中的措辞中。

将当前[p10]改为：

函数模板F至少和函数模板一样专业 G 当且仅当：

• 对于用于确定排序的每一对类型，F 中的类型至少与 G 中的类型一样专业，并且，
• 使用转换后的F作为参数模板，G作为参数模板进行推演时，推演完成后 对于所有类型对，类型中使用的所有模板参数来自 用于确定排序的G 具有值，而那些 所有类型对的值都是一致的。

F 比G 更专业 如果F 至少和F 一样专业 因为G 和G 至少不像F 那样专业。

将整个当前 [p11] 记为笔记。

（分辨率1391添加到[14.8.2.5p4]的注释也需要调整——[14.8.2.1]可以，[14.8.2.4]不行。）

---

对于 MSVC，在某些情况下，P 中的所有模板参数看起来都需要在推演期间接收特定 P / A 对的值才能成功推演从A 到P。我认为这可能是导致您的示例和其他示例中的实现分歧的原因，但我至少见过一种情况，上述情况似乎并不适用，所以我不确定该相信什么。

上述语句似乎确实适用的另一个示例：在您的示例中将 template<typename T> void bar(T, T) 更改为 template<typename T, typename U> void bar(T, U) 会交换结果：调用在 Clang 和 GCC 中不明确，但在 MSVC 中解析为 b。

一个没有的例子：

#include <iostream>

template<class T> struct A { using a = T; };
template<class, class> struct B { };

template<class T, class U> void f(B<U, T>) { std::cout << "#1\n"; }
template<class T, class U> void f(B<U, typename A<T>::a>) { std::cout << "#2\n"; }

int main()
{
   f<int>(B<int, int>());
}

这在 Clang 和 GCC 中选择了#2，正如预期的那样，但 MSVC 拒绝了这个不明确的调用；不知道为什么。

---

标准中描述的偏序算法谈到合成唯一的类型、值或类模板以生成参数。 Clang 通过......不合成任何东西来管理它。它只是使用依赖类型的原始形式（如声明的那样）并以两种方式匹配它们。这是有道理的，因为替换合成类型不会添加任何新信息。它不能更改 A 类型的形式，因为通常无法判断替代形式可以解析为哪些具体类型。合成的类型是未知的，这使得它们与模板参数非常相似。

当遇到一个非推导上下文的P 时，Clang 的模板参数推导算法会简单地跳过它，为该特定步骤返回“成功”。这不仅发生在偏序期间，而且发生在所有类型的推导中，并且不仅发生在函数参数列表的顶层，而且每当遇到复合类型形式的非推导上下文时都会递归。出于某种原因，我第一次看到它时感到很惊讶。想一想，它当然是有道理的，并且符合标准（[...] 不参与类型推导 [...] in [14.8.2.5p4] )。

这与Richard Corden's cmets 到his answer 一致，但我必须实际查看编译器代码才能理解所有含义（不是他的答案的错误，而是我自己的错误——程序员在代码中思考等等那个）。

我在this answer 中包含了有关 Clang 实现的更多信息。

Answer 2

我认为关键在于以下陈述：

第二个参数是一个非推导的上下文 - 那么如果 UniqueA 可以转换为 identity::type，那么推导不会成功吗？

类型推导不执行“转换”检查。这些检查使用真正的显式和推导参数作为重载决议的一部分进行。

这是我对选择要调用的函数模板所采取的步骤的总结（所有引用取自 N3937，~ C++ '14）：

1. 显式参数被替换，结果函数类型检查它是否有效。 (14.8.2/2)
2. 执行类型推导并替换推导得到的参数。同样，结果类型必须是有效的。 (14.8.2/5)
3. 在第 1 步和第 2 步中成功的函数模板是专用的，并包含在用于重载解决方案的重载集中。 (14.8.3/1)
4. 转换序列通过重载分辨率进行比较。 (13.3.3)
5. 如果两个函数特化的转换序列不是“更好”，则使用偏序算法来查找更特化的函数模板。 (13.3.3)
6. 偏序算法仅检查类型推导是否成功。 (14.5.6.2/2)

编译器在第 4 步已经知道，当使用真正的参数时，可以调用这两种特化。第 5 步和第 6 步用于确定哪些功能更专业。