Question

C++98 有个如何编写提案的指南 [Stroustrup et al. 1992]，但奇怪的是，演化组并没有为提给 C++14、C++17 或 C++20 的提案准备一份检查清单。有一份针对标准库提案的检查清单 [Meredith 2012]。对于 C++20，国家标准机构负责人的一份说明 [van Winkel et al. 2017] 和 Direction Group 的一份文件 [Hinnant et al. 2019] 给出了一些指导。以下是一个简短而不完整的问题清单，这些问题几乎总会被提给一项提案：

• 要解决的问题是什么？将为什么样的用户提供服务？新手？专家？
• 解决方案是什么？阐明它所基于的原则。给出简单的使用案例和专家级的使用案例。
• 有哪些替代解决方案？库解决方案是否足够？为什么现有功能不够好？
• 为什么解决方案需要在标准中？
• 采用该技术存在哪些障碍？从现有的技术过渡可能需要多久？
• 已经实现了吗？在实现过程中遇到了或预期会遇到哪些问题？有用户体验吗？
• 会不会有很大的编译期开销？
• 该特性是否能融入到现有工具和编译器的框架中？
• 与变通方案相比，会有运行期开销吗？在时间上？在空间上？
• 会有兼容性问题吗？会破坏现有的代码吗？ABI 会被破坏吗？
• 新功能将如何与现有功能和其他新功能交互？
• 解决方案是否容易教授？教给谁？谁来教？
• 标准库会受到怎样的影响？
• 该提案是否会导致对未来标准进一步扩展的要求？
• 该特性在标准里如何措辞表达？
• 用户在使用新功能时可能会犯哪些错误？
• 就整个 C++ 社区的利益而言，该提案是否属于前 20 名？前 10？
• 该提案是否属于特定子社区的前三名？哪个子社区？
• 该提案是解决某一类问题的通用机制还是某个特定问题的特定解决方法？如果是针对一类问题，是哪一类问题？
• 该提案在语义、语法和命名方面是否与语言的其余部分一致？

理想的情况是，一项提案能够回答所有这些问题，甚至更多，但这种情况很少发生。特别是，在最初的提案中，理由往往非常薄弱，因为提案者认为所处理的 问题的重要性和他们建议的解决方案非常明显。然而，后续的论文、修改、电子邮件讨论和演化组的面对面讨论通常都会涉及这些问题，但很少对各个提案进行系统 的或一致的检查。成员们倾向于关注技术细节（例如，语法、歧义、优化机会和命名），而不是重新探讨根本问题。有时，我所认为的糟糕的提案会混进去。原因通 常是提案者的极大热情加上反对者的分心、礼貌和疲惫 [Stroustrup 2019b]。