Question

我一直努力鼓励委员会关注重要的改进——而不只去做那些容易完成和容易达成一致的事情——作为这个努力的一部分，我制定了一个清单，包含了我认为重要且适合引入 C++17 的内容及其理由：

• 概念——它让我们可以精确描述泛型程序，并解决对于错误信息质量的广泛抱怨。
• 模块——只要它可以显著地提高与宏的隔离并大大优化编译时间。
• 范围库和其他关键 STL 组件对概念的使用——为主流用户改进错误信息质量和提高库规范的精确性（STL2）。
• 统一调用语法——简化模板库的规范和使用。
• 协程——应该非常快速而简单。
• 网络库支持——基于 asio 库，如相应 TS 所描述。
• 契约——不一定需要在 C++17 的库规范中使用。
• SIMD 向量和并行算法。
• 标准库词汇类型，比如 optional、variant、string_view 和 array_view。
• 一种在栈上提供数组（stack_array）的魔法类型，合理支持安全、便捷的使用。

在 2015 年 4 月份，在 Kansas 州 Lenexa 的 WG21 会议中，我在晚间会议上向一些有共鸣的观众展示了这个清单。然而，几乎没有人感受到足够的动力去根据这个清单调整工作焦点。这个清单后来泄露了出去，并且在网上引起了混乱的讨论，因此我不得不把它正式写出来 [Stroustrup 2015a]。

如果是在一个团结的委员会中，该清单上的每一项都应该已经准备好进入 C++17 了。实际上我认为，如果我们专注于这个列表，完成其中的大约一半提案还是可行的。然而我还是过于乐观了。我们唯一达成共识的也就只有关于标准库词汇类型的那一项。其中 array_view 被重命名为 span，成了 C++20（§9.3.8）的一部分。

幸运的是，列表上的大部分条目进入了 C++20。除了

• 网络库（§8.8.1）——现在是个 TS [Wakely 2018]
• 契约（§9.6.1）——差一点进入 C++20
• 统一函数调用（§8.8.3）
• SIMD 向量——目前在一个 TS 中 [Hoberock 2019]
• stack_array

这份列表带来了日程安排上的争论。鉴于概念的提案（§6.3.8） 在 2016 年的失败看起来是不可避免了，我被询问——由整个委员会——是否我打算提议推迟标准的发布一到两年，来把概念加入到标准中，让标准变成 C++18 或者 C++19。我拒绝了，因为我认为可预见的发布周期对于整个社区而言更为重要，其重要性要超过某个单项的改进。而且，当时也无法确保一定会就该提案形成共 识，再说一次日程延误很可能会造成更多的延误。如果一份提案被认为值得推迟标准发布，那么就会有人主张也有其他的提案同样值得标准发布的推迟。这样的逻辑 使得 C++0x 变成了 C++11，哪怕当时曾有人希望是 C++06。