GCC和clang（SFINAE）过载分辨率行为差异

Question

GCC接受以下代码：

template <typename T>
struct meta
{
    typedef typename T::type type;
};

struct S {};

template <typename T>
typename meta<T>::type foo(T, S);

int foo(int, int);      

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

但是clang拒绝它并带有以下错误：

test.cpp:4:22: error: type 'int' cannot be used prior to '::' because it has no members
    typedef typename T::type type;
                     ^
test.cpp:10:10: note: in instantiation of template class 'meta<int>' requested here
typename meta<T>::type foo(T, S);
         ^
test.cpp:10:24: note: while substituting deduced template arguments into function template 'foo' [with T = int]
typename meta<T>::type foo(T, S);
                       ^

这似乎表明GCC和clang在重载解析期间执行某些操作的顺序有所不同。GCC似乎在尝试实例化模板候选者的返回类型之前抛弃了模板候选者，因为第二个参数（Svs.int）中的类型不匹配，而clang似乎反过来做。

谁是对的？

我相信这个问题对模板库的作者有着重要的意义。具体来说，如果clang是正确的，那么模板foo的作者将不得不做额外的工作，将错误转化为替换失败。

编辑：请注意，GCC和clang都拒绝了以下稍微简单的示例，但出现了类似的错误：

template <typename T>
struct meta
{
    typedef typename T::type type;
};

template <typename T>
typename meta<T>::type foo(T);

int foo(int);      

int main()
{
    foo(0);
}

建议GCC知道“只有函数类型及其模板参数类型的直接上下文中的无效类型和表达式才能导致推断失败”。本例与原始示例之间的区别在于原始示例中存在第二个html" target="_blank">函数参数，在此基础上，GCC甚至在尝试对返回类型执行替换之前就抛出了模板候选。我认为问题是，GCC是否正确地按照这个顺序进行操作，还是应该在考虑参数类型中的匹配之前尝试对返回类型执行替换。

更新：Luc Danton的回答让我相信clang拒绝代码是正确的。因此，我提交了一个GCC错误。

Answer 1

C 03将此措辞作为通常称为SFINAE的规范的一部分（14.8.2模板参数扣除[temp.Decreate]，第2段）：

[...]如果模板参数或函数模板的函数类型中的替换导致无效类型，则类型推导失败。[...]

相比之下，C 11使用了以下措辞（14.8.2模板参数扣除[临时扣除]，第8段）：

如果替换导致无效类型或表达式，则类型推导失败。[...]只有函数类型及其模板参数类型的直接上下文中的无效类型和表达式才能导致推导失败。[...]

重点是我的。据我所知，C 11中的措辞得到了改进，明确地概述了什么应该导致SFINAE（所谓的软错误）和什么不应该导致SFINAE（硬错误）。这篇2008年的论文是当时正在进行的讨论的一个例子，它导致了当前的规则。

考虑到这一点，可能是这样的情况，根据C 03一个实现可能是正确的接受你的代码（甚至可能应该）。我怀疑C 11实现应该拒绝它但是：错误（int::type）是在meta的上下文中

Answer 2

在这里，叮当声和g声都是正确的。

根据Luc Danton的回答，编译器可以推导出foo函数模板的T=int。然后，在将该值替换为foo声明的过程中，meta的隐式实例化

然而，[temp.inst]p7说：

如果重载解析过程可以在不实例化类模板定义的情况下确定要调用的正确函数，则未指定该实例化是否实际发生。

因为非模板foo与调用中的参数完全匹配，所以编译器可以确定函数模板特化永远不会是最好的可行函数，因此不需要执行参数推导和替换。因此g不拒绝此代码是正确的。