为何C++17标准未引入类模板参数的部分推导机制？

这确实是C++里一个挺让人挠头的场景——想优雅地用lambda做容器的自定义比较器，却被模板推导的规则卡着。咱们一步步拆解这个问题：

现有实现方案的痛点 #

先回顾你提到的几种写法，各自都有明显的短板：

1. C++11的std::function包装方案 #

std::set<int, std::function<bool(int, int)>> s([](int a, int b) {return a > b;});

问题：std::function是基于类型擦除的包装器，会带来额外的运行时开销（比如隐式的虚函数调用、甚至堆内存分配），性能远不如直接用lambda的闭包类型作为比较器。

2. 借助decltype的方案 #

auto mycomp = [](int a, int b) {return a > b; };
std::set<int, decltype(mycomp)> s(mycomp);

不足：

• 必须拆分两行代码，额外定义一个mycomp变量，不够简洁；
• 因为lambda的闭包类型没有默认构造函数，必须显式把比较器实例传入容器构造函数，多了一步冗余操作。

为什么标准不支持部分模板参数推导？ #

你说的没错，C++17的类模板参数推导（CTAD）确实只在完全不指定模板参数列表时才会触发——只要你写了哪怕一个模板参数，推导就会直接禁用，必须手动补全所有参数。至于背后的原因，主要有这几个考量：

1. 语法歧义与实现复杂度 #

如果允许std::set<int, auto>这种部分指定的写法，编译器需要明确区分哪些参数是用户固定的、哪些是需要推导的。但模板参数的位置是有语义的，比如std::set的参数顺序是T, Compare, Allocator，要是用户写std::set<auto, decltype(mycomp)>，编译器怎么判断第一个参数要推导、第二个固定？

这种规则会让模板推导的逻辑变得异常复杂，不仅增加编译器实现的难度，还容易让用户写出混淆的代码，引发歧义。

2. 设计目标的权衡 #

CTAD的核心设计目标是让模板类的实例化像普通类一样简洁，比如std::vector v{1,2,3}就能自动推导出std::vector<int>。它主要针对的是完全省略模板参数的通用场景，而不是你说的这种"部分指定、部分推导"的小众场景。

标准委员会在引入新特性时，会优先考虑通用性和简洁性，避免过度复杂化语法。虽然你的需求很实用，但它的适用范围相对较窄，而且可以通过其他方式绕开，因此没有成为优先支持的特性。

3. 向后兼容性风险 #

如果引入部分模板参数推导，可能会破坏现有代码的兼容性。比如某些现有模板已经定义了特定的推导指引，或者用户的代码依赖于当前"指定参数则不推导"的规则，引入新特性后可能会导致意外的编译错误或行为改变。

临时的折中方案 #

虽然标准不支持，但我们可以自己封装一个工厂函数来实现类似的效果：

template<typename T, typename Compare>
auto make_set(Compare comp) {
    return std::set<T, Compare>(std::move(comp));
}

// 使用方式：一行代码搞定
auto s = make_set<int>([](int a, int b) { return a > b; });

这样既避免了std::function的性能开销，又能保持代码的简洁性，算是一个不错的 workaround。

内容的提问来源于stack exchange，提问作者Kaznov