Question

在 2017 年，作为 C++20 的最早特性之一，WG21 将 Concepts TS [Sutton 2017] 中基础部分和无争议的部分通过投票进入了工作文件（§6.3.2）：

• 为通用起见，显式使用 requires 语句；例如 requires Sortable<S>
• 简略写法，用于表示类型的类型；例如 template<Sortable S>

自然写法（例如 void sort(Sortable&);（§6.3.7））因有争议而被排除在外。被排除在外的原因有以下几点：

• void sort(Sortable&); 是一个模板，但这不很明显。
• void f(C&&); 的含义取决于 C 是概念还是类型。
• 在 Iterator foo(Iterator,Iterator); 中，三个 Iterator 必须是相同类型，还是可以分开约束的类型？
• 自然语法令人困惑且难以教授。
• 我们如何约束 template<auto N> void f(); 中的参数？

这些异议并不新鲜，但这次它们伴随着许多使用全新语法的提案 [Honermann 2017; Keane et al. 2017; Köppe 2017a; Riedle 2017; Sutter 2018a]。这些提案各不相同，和 Concepts TS 也不兼容。人们带着热情在会议上介绍这些提案，而其中没有一个有实际经验的支持。相比之下，我的立场是基于约四年的教学经验、很多的实验使用、一些业界应 用，以及在几个标准库提案组件中的使用（如，迭代器封装 [Dawes et al. 2016]、元组实现 [Voutilainen 2016b]、范围 [Niebler et al. 2014]）。

在 Jacksonville 会议（2018）上，Tom Honerman 建议删除自然语法，并提出了另一种选择 [Honermann 2017]。我捍卫了自己的立场和 Concepts TS 的设计 [Stroustrup 2017a,b]。我的辩护主要是

• 五年多来，自然语法在实际教学和使用中未引起任何问题。
• 用户喜欢它。
• 没有技术上的歧义。
• 它简化了常见用法。
• 这是使泛型编程更像普通编程的动力之一。

但这未能说服任何反对者，因此自然语法没有移到 C++20 的工作文件中。

最后一个反对意见来自 C++17 的一个新的小特性，auto 值参数 [Touton and Spertus 2015]，并成为反对的焦点：

template<auto N> void f();

人们想在语法上区分值模板参数和类型模板参数。通常，这意味着自 2002 年以来一直在提案里被使用的简写语法将不再有效。

template<Concept T> void f(T&); // 建议被废止

在 2018 年中，我提出了一个最小折中方案 [Stroustrup 2018b]：

• 保留 template<Concept T> void f(T&); 的含义；
• 使用前缀 template 来识别使用自然写法的模板（例如 template void f(Concept&)）

提议成功了，但是 Herb Sutter [Sutter 2018a] 提出的一个截然不同的建议也成功了 [Sutter 2018a]。我们当时处于一种非常特殊的境地，同时有两个截然不同且互不兼容的提案，每个都得到了 EWG 的大多数人的支持。这种僵局为 Ville Voutilainen（EWG 主席）提出一种变通方案打开了大门，这一方案在 2018 年 11 月得到了广泛的支持并被接受 [Voutilainen et al. 2018]：

• 保留 template<Concept T> void f(T&); 的含义
• 使用 auto 来识别使用自然写法的模板参数，例如 void f(Concept auto&);

举例来说：

// 几乎自然的写法：
void sort(Sortable auto& x);  // x 必须 Sortable
Integral auto ch = f(val);    // f(val) 的结果必须为 Integral
Integral auto add(Integral auto x, Integral auto x); // 可以用一个更宽的
                                                     // 类型来防止溢出

自然写法已重命名为缩写语法，虽然它不仅仅是一个缩写。

尽管我认为在这种 auto 的使用有些多余，分散和损害了我想使泛型编程变成普通编程的目标，但我还是支持这种折中方案。也许在将来的某个时候，人们会（正如当时 Herb Sutter 所暗示的那样）达成一致，让在概念名后的 auto 不再必要。不过，我并没有抱太大的希望；很多人认为为技术实现而定义的语法标记很重要。或许 IDE 的自动完成功能可以使用户免于手写这多余的 auto。

遗憾的是，对于重新引入概念名称引导器并没有达成共识（§6.3.4）。缺乏足够传统的语法是一个主要的绊脚石。同样，仍然有很多人似乎不相信其有用。

延迟很多年才引入概念造成了长期的伤害。基于特征（traits）和 enable_if 的临时设计数量激增。一代程序员在低级的、无类型的元编程中成长起来。