参数包必须在参数列表的末尾...何时以及为什么？

Question

如果参数列表绑定到一个类，我不明白参数包必须位于参数列表末尾的原因，而如果参数列表是成员方法声明的一部分，则放宽约束。

换句话说，这个编译：

class C {
    template<typename T, typename... Args, typename S>
    void fn() { }
};

以下一项没有：

template<typename T, typename... Args, typename S>
class C { };

为什么第一种情况被认为是正确的，而第二种情况则不是？
我的意思是，如果它是合法的语法，不应该在这两种情况下都适用吗？

要清楚，真正的问题是我定义了一个类似于以下的类：

template<typename T, typename... Args, typename Allocator>
class C { };

将分配器类型作为最后一种类型将不胜感激，但我可以以某种方式解决它（无论如何，如果您有任何建议，我们将不胜感激，也许您的建议比我的要优雅得多！）。
也就是说，我得到了错误：

参数包'Args'必须在模板参数列表的末尾

所以，我只是想完全理解为什么它在某些情况下被接受，但在其他一些情况下却不是。

Here 是一个类似的问题，但它只是解释了如何解决问题，这对我来说很清楚。

Answer 1

它对函数模板有效，但只有当参数推导可以帮助编译器解析模板参数时，你的函数模板示例实际上是无用的，因为

template<typename T, typename... Args, typename S> void fn() { }
int main() { fn<int, int, int>(); }

test.cpp: In function 'int main()':
test.cpp:2:32: error: no matching function for call to 'fn()'
 int main() { fn<int, int, int>(); }
                                ^
test.cpp:1:57: note: candidate: template<class T, class ... Args, class S> void fn()
 template<typename T, typename... Args, typename S> void fn() { }
                                                         ^
test.cpp:1:57: note:   template argument deduction/substitution failed:
test.cpp:2:32: note:   couldn't deduce template parameter 'S'
 int main() { fn<int, int, int>(); }

编译器无法确定哪些模板参数属于参数包，哪些属于S。实际上就像@T.C.指出它实际上应该是一个语法错误，因为以这种方式定义的函数模板永远无法实例化。

一个更有用的函数模板是这样的

template<typename T, typename... Args, typename S> void fn(S s) { }

因为现在编译器能够明确地将函数参数s 与模板类型S 匹配，其副作用是S 将总是被推导出 - 所有显式模板参数第一个之后将属于Args。

这些都不适用于（主要）类模板，不会推导出参数并且明确禁止：

来自草案 n4567

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4567.pdf

[温度参数] / 11

[...]如果主类模板或别名的 模板参数 template 是一个模板参数包，应该是最后一个 模板参数.[...]

（如果它们被推导出来，就会像函数模板示例中那样模棱两可）。

Answer 2

第一个是不对的。编译器有问题，无法诊断。 [temp.param]/11:

不应遵循函数模板的模板参数包 由另一个模板参数，除非该模板参数可以 从函数模板的 parameter-type-list 推导出来或具有 默认参数 (14.8.2)。

---

如果函数类型 T(Args...) 对最终用户有意义，解决此问题的一种方法是改用部分特化：

template<class F, class Alloc> class C; //undefined
template<class T, class... Args, class Alloc>
class C<T(Args...), Alloc> {
    // implementation
};

根据实际需求，对分配器进行类型擦除可能也值得考虑。