Question

C++ 是由一个大型委员会控制的，成员多种多样，并且会不断变化（§3.2）。因此，除了技术问题外，我们必须考虑在语言的演化过程中什么是有效的：

• 问题驱动：C++ 开发应该被那些真实世界中的具体问题的需求所驱动。
• 简单：C++ 应该从简单、高效、易用的解决方案中进行推广而成长。
• 高效：C++ 语言和标准库应该遵循零开销原则。
• 稳定性：不要搞砸我的代码！

大部分（全部？）C++ 最成功部分的开发都遵从了那些经验法则。它们自然会限制语言的发展范围，但这是好事。C++ 并不意味着对所有的人都是无所不能的。此外，这些原则迫使 C++ 在现实世界的挑战中相对缓慢地成长，并从反馈中受益。也请参见《C++ 语言的设计和演化》中的其他经验法则 [Stroustrup 1994] 和我的 HOPL2 论文 [Stroustrup 1993]。这里面一直有连续性。

相比之下，一个功能如果设计时没有明确专注在解决大部分开发者实际面临的问题上，那它通常会失败：

• 只为专家：某个功能从开始的时候就要满足所有专家的需要。
• 模仿：我们需要这个功能，因为它在另外某个语言里很流行。
• 理论性：语言理论里说语言里一定要有这个特性。
• 革命性：此功能非常重要，以至于我们必须打破兼容性，或者摒弃那些不好的老方法。

我的结论是，尽早确定方向和期望至关重要。稍晚一些，就会有太多的人有太多的不同意见，因而无法达成一套连贯而一致的想法。

给定一个方向和一组原则，一种语言可以基于不同的工具来发展，如反馈、用户体验、实验和理论。这是好的工程方法；反之，则是无原则的实用主义或教条的理想主义。

C++ 标准委员会的章程几乎只关注语言和库的设计。这是有局限性的。一直以来，像动态链接、构建系统和静态分析之类的重要主题大多被忽略了。这是个错误。工具是软件开发人员世界的一个重要组成部分，要是能不把它们置于语言设计的外围就好了。

热衷于各种不同的想法具有危险性。在 2018 年的一篇论文 [Stroustrup 2018d] 中，我列出了 51 条最近的提案：

我列出了我认为有可能显著改变我们编写代码方式的论文，每一篇对教学、维护和编码指导都有重要的影响，其中许多对实现也有影响。

单独来说，许多（大多数）提案都是有道理的，但是放在一起却是疯狂的，甚至足以危及 C++ 的未来。

那篇论文的题目是《记住瓦萨号！》（Remember the Vasa!）。瓦萨号是 17 世纪瑞典的一艘宏伟战舰，由于设计上不断后期添加以及测试不充分，在首航时就沉没在斯德哥尔摩港。在 1990 年代，委员会经常提醒自己记得瓦萨号，但在 2010 年代，这一教训似乎已经被遗忘。

为了对委员会的流程进行组织约束，方向组提出 C++ 程序员的权利法案 [Dawes et al. 2018]：

1. 编译期稳定性：新版本标准中的每一个重要行为变化都可以被支持以前版本的编译器检测到。
2. 链接期稳定性：除极少数情况外，应避免 ABI 兼容性破坏，而且这些情况应被很好地记录下来并有书面理由支持。
3. 编译期性能稳定性：更改不会导致现有代码的编译时间开销有明显增加。
4. 运行期性能稳定性：更改不会导致现有代码的运行时间开销有明显增加。
5. 进步：标准的每一次修订都会为某些重要的编程活动提供更好的支持，或为某些重要编程群体提供更好的支持。
6. 简单性：每一次对标准的修订都会简化某些重要的编程活动。
7. 准时性：每一次标准的修订都会按照公布的时间表按时交付。

接下来的几十年，我们将会看到结果到底怎么样。