Question

从近期来说，C++20 会像 C++11 那样，让 C++ 社区受益良多。在 2020 年 2 月的布拉格会议上，委员会对 C++20 进行了定稿，也投票同意了 Ville Voutilainen 的C++23 大胆计划 [Voutilainen 2019b]：

在 C++23 努力做到以下几点：

• 对协程的库支持（§9.3.2）
• 模块化的标准库（§9.3.1）
• 通用异步计算模型（执行器）（§8.8.1）
• 网络（§8.8.1）

注意关注点是在库上。同时也在以下方面取得进展：

• 静态反射功能（§9.6.2）
• 函数式编程风格的模式匹配（§8.2）
• 契约（§9.6.1）

鉴于这些议题的工作已经相当深入，委员会有可能会完成大部分工作。这一大群充满热情的人还能拿出什么东西并达成共识，就不那么容易预测了。对于未来几年，方向小组（我是其中的一员）提到了一些有希望进一步开展工作的领域 [Hinnant et al. 2020]：

• 改进 Unicode 的支持
• 支持简单图形和简单用户交互
• 支持新类型的硬件
• 探索错误处理的更好表达方式和实现方法

在委员会之外，我期望在构建系统、包管理和静态分析方面取得重大进展（§10.4）。

再往后的五年、十年或更远的未来，我在预测水晶球里就有点看不清了。在这个时间范围内，我们需要着眼于根本，而不是具体的语言特性。我希望标准委员会能注意到学到的教训（§11.4），并把重点放在根本上（§11.1）：

• 把完全资源安全和类型安全的 C++ 作为追求目标
• 很好地支持各种各样的硬件
• 保持 C++ 的稳定性记录（兼容性）

保持稳定性需要在关注兼容性的同时，抵制试图通过添加大量完美特性来取代不完美或不时髦的旧方式来大幅改善 C++ 的冲动。新的特性总是会带来意外（有些令人愉快，有些则不那么令人愉快），旧的特性不会简单地消失。记住瓦萨号！[Stroustrup 2018d]（§11.4）。很多情况下，库、指南和工具是比修改语言更好的方法。

对于单线程计算来说，硬件已无法变得更快，所以对效率的重视将持续存在，而有效支持各种形式的并发和并行的压力将不断增加（§2.3）。专用硬件将大量涌现（例如，各种内存架构和特殊用途的处理器）；这将使 C++ 这样的、可以利用这些硬件的语言受益。唯一比硬件性能增长更快的是人们的期望。

随着系统越来越复杂，开销可负担的抽象机制的重要性也在增加。对于依赖实时交互的系统，可预测的性能是至关重要的（例如，许多实时系统禁止使用自由存储（动态内存））。

随着我们对计算机化系统的依赖程度的增加、高手黑客数量的增多，安全问题只会越来越重要。为了防御，我看好硬件保护，看好更结构化、能支持更好的静态分析的系统，而非无休止的临时运行期检查和低级代码。

语言和系统之间的互操作性仍会至关重要；很少有大系统会只用一种语言来编写。

随着系统变得越来越复杂，对可靠性的要求也越来越高，对设计和编码质量的需求也急剧增加。我认为 C++ 已经为此做好了充分的准备，C++23 的计划是要进一步加强它。然而，仅靠语言特性是不足以满足未来需求的。我们需要有工具支持的使用指南，以确保语言的有效使用（§10.6）。 特别是，我们需要确保完全的类型安全和资源安全，这必须反映在教育中。为了蓬勃发展，C++ 需要为新手提供更好的教育材料，也需要帮助有经验的程序员掌握现代 C++。仅仅介绍奇技淫巧和高级用法是不够的，而且反而会因为增强了 C++ 的复杂性名声而对语言造成伤害。

由于种种原因，我们需要简化大多数的 C++ 使用的场景。C++ 的演进已经使之成为可能，而我预计这一趋势将继续下去（§4.2）。 改进的优化器——有能力利用代码中使用的类型系统和抽象——让优化这件事变得不同了。在过去的几年里，这极大地改变了我优化代码的方式。我从放弃精巧而复 杂的东西开始，那是错误的藏身之处；并且，如果我难以理解发生了什么，编译器和优化器也会如此。我发现，这种方法通常会给我带来从适度到惊人的性能提高， 同时也简化了未来的维护。只有当这种方法不能给我带来我想要的性能时，我才会求助于高级（又称复杂）的数据结构和算法。这是 C++ 抽象机制设计上的一大胜利。

我期待着看到用 C++ 构建更多令人兴奋的应用程序，并看到新的编程惯用法和设计技巧的发展。

我也希望其他语言能从 C++ 的成功中学习。假如从 C++ 的演化中吸取的经验教训仅局限于 C++ 社区，那将是可悲的。我希望并期待在其他语言和系统中看到 C++ 模型的关键方面，这将是一个真正的成功衡量标准。在一定程度上，这已经发生了（§2.4）。