记一次开诚布公的交流！在 WG21 谈 C++ 标准化的实现现状与挑战
引言
在 2025 年美国夏威夷科纳（Kona）举行的 WG21（即 C++ 标准委员会）会议上，共有 20 位现场参与者和 9 位远程参与者，围绕大家实际工作中面临的挑战展开深入交流。为营造一个安全、信任的交流空间，会议有意采用闭门形式，并明确鼓励与会者以开放、诚实、不加滤镜的方式表达各自的观点，确保每一位参与者的声音都能被充分倾听。
与会者利用一个晚上的时间进行了坦诚而深入的对话。实现者们（是指 C++ 标准的实现者，例如编译器、标准库的实现者）在《Implementation reality of WG21 standardization》 这篇文章中总结了本次讨论，首个中国企业代表阿里云许传奇在该文章中署名。本文即是对此次讨论的全面总结，不仅记录了会上提出的主要关切类型，还进一步提出了应对这些问题的具体建议。
原文链接：https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3962r0.pdf
讨论主题
以下并非讨论主题的完整清单，为简洁起见，仅列出了主要议题。
成本、资源与经济现实
与会者强调，有必要提升对各项特性真实成本的可见性，并在此基础上建立各方的共同理解。尽管单个提案通常会基于其技术优点和基本可行性进行评估，但在委员会的讨论过程中，长期累积的实现、维护、测试和支持成本往往缺乏足够的透明度。
当前，编译器和标准库的开发面临显著的资源限制。许多实现者是志愿者，或仅获得部分资金支持其参与标准化工作，且通常没有专职人员负责实现所有已纳入标准的特性。因此，在实践中，完全符合最新 C++ 标准仍然十分困难——一些实现仍在努力达成 C++20 的合规性，而对更新标准的采纳能力则更为有限。当某些特性无法在所有供应商的实现中获得支持时，C++ 标准的可移植性便受到损害，进而降低其被开发者广泛采用的可能性。
会上，与会者进一步指出，实现成本并不仅限于初始开发阶段。持续的维护负担、性能的潜在影响、ABI 稳定性要求、测试矩阵的不断扩展，以及与现有特性的复杂交互，都会显著增加长期的技术和工程负担。
大家普遍认为，若能在标准制定过程中更清晰地承认这些成本与权衡，将有助于改善整体决策质量。此外，我们更应充分认识到：向标准中新增特性，必然会挤占其他工作的时间，包括缺陷修复、合规性改进、性能调优，以及各类高价值的标准库增强。
实现者的声音与实现复杂性的理解
与会者表达了担忧：实现者的角色和专业知识在委员会流程中（尤其是在早期设计讨论阶段）始终未得到充分体现。实现反馈常常在后期才被引入，且常被视为阻碍进展的对立意见，而非必要的设计输入。若能在流程早期更充分地体现并重视实现者的视角，将有助于确保设计方案既在技术上合理，又具备实际部署可行性。
多位参与者指出，有时存在一种隐含假设，即提案“易于实现”，但这种假设所依据的心理模型往往未能反映大型、成熟代码库的真实情况。实际上，看似微小或局部的改动可能需要大量重构，与现有特性产生意外交互，或带来显著的测试和维护成本。区分“理论上的可能性”与“实践中的可行性”被认定为一个重要的视角，但目前这一视角并未被一致应用。
另一个担忧是，委员会的讨论有时会影响工具链中的某些领域（尤其是中间表示优化器），而这些领域的相关专家在常规委员会参会者中代表性不足。这偶尔会导致提案中未充分考虑的实现问题。
与会者还指出，当前所谓的“实现经验”往往不足以评估现实世界的可行性。部分原型、本地分支或概念验证实现虽有助于探索想法，但很少能反映将特性合并到主干、跨多种大型异构代码库进行维护、测试和部署所需的实际工作量。同样，基于某一特定实现构建的原型也无法直接推广到所有实现，因为不同实现对同一特性的成本可能存在巨大差异。此外，尽管我们鼓励为新特性积累实现经验，但会议也指出，委员会应更进一步，将实现经验作为新特性进入标准的必要条件。
总体而言，与会者强调，实现者不仅负责措辞或事后执行，更肩负着将标准转化为在真实系统中连贯、高效、可用的实现的责任。建立更能认可这一责任的流程，并提供清晰、受尊重的渠道以提出关切，被视为改善委员会和用户双方成果的关键。
参与演化（Evolution）与措辞（Wording）工作的挑战
实现者表示同时参与演化和措辞工作的巨大困难，并提到提案数量庞大、并行的研究小组众多，以及讨论节奏快速，已经对本就有限的实现者时间造成了沉重负担。而 EWG/LEWG 与 CWG/LWG 的并行运作进一步加剧了这一挑战，使得实现者难以在早期设计讨论中做出有意义的贡献，同时又参与细节语义工作。
结果是，实现方面的关切往往在设计方案推进较深后才被提出，此时再修改决策代价高昂且具有破坏性。反之，设计讨论也可能在缺乏及时语义约束输入的情况下进行，而这些约束后续需在措辞小组中处理，从而增加了返工和各小组间不一致的风险。
委员会优先事项、用户需求与管理层期望之间的协调
实现者指出，管理层的决策极大地影响了最终哪些特性会被实现和部署。管理层通常优先考虑稳定性、可移植性、性能和明确的用户价值，而不太愿意为仅惠及少数高级用户、或在缺乏明确采用需求的情况下增加复杂性的特性提供资金支持。因此，即使某项特性已获委员会批准，若不符合组织优先级或用户需求，也可能不会被实现。
此外，尽管某个提案可能契合作者所考虑的客户群体，但实现者往往服务于需求和优先级各异的多个客户群体。
新特性 vs 缺陷修复与可移植性
与会者强调，在开发新特性和持续关注缺陷修复、合规性及整合工作之间取得平衡至关重要。新特性的开发会占用解决现有缺陷和核心未决问题的时间，同时往往又会向标准中引入新的缺陷。所有这些未解决的问题导致各实现的行为和解释出现分歧，直接影响可移植性——在某一实现上正常工作的代码，在另一实现上可能表现不同甚至失败。
当特性的积累速度超过其被完整实现、集成和调整的能力时，它们便叠加在不完整或不一致的基础之上，进一步增加了代码不可移植的风险。
多位参与者建议，委员会应投入更多精力解决缺陷和实施高价值修复，这将有助于在不同平台和实现上获得更可预测、更具互操作性的 C++ 代码，并促进现有特性的采用。
建议行动
提高成本与权衡的可见性
我们希望委员会开始探索机制，使成本、资源消耗和技术债务的影响更加明确，或尝试为每个发布版本设定总体成本预算。我们应认识到，将特性写入标准并非终点，而应更务实地看待我们所拥有的资源。
更早整合实现者反馈
我们呼吁委员会探索在流程早期收集实现者反馈的方法。一种可行方式是设立一个“实现者咨询研究小组”。该小组可为提交的每一项提案提供强制性反馈。此类小组可提供的信息示例包括：
该特性按当前规范是否可行？
对特定实现而言，该特性的成本是多少？
特定用户群体或管理层对该特性是否有需求？
对参考实现的反馈
若该小组能通过 GitHub Issues 等渠道持续运作，将特别有助于那些因时间和资源限制无法参加委员会会议的实现者贡献观点。设立此类研究小组的另一好处是能促进实现者之间的协作，这也是会议中提出的另一议题。
调整节奏与发布重点
我们希望委员会考虑减缓向标准中添加新特性的速度，以便实现者能够跟上进度，并提升现有特性的质量。
委员会可考虑延长标准化周期，或交替采用“以新特性为重点”和“以整合巩固为重点”的发布模式。
我们还应明确将缺陷修复、合规性和可移植性工作与新特性置于同等优先地位。
减少日程安排与参会冲突
建议委员会尽可能避免并行运行演化组和措辞组，这将使具备深入知识的人员能在设计决策阶段在场，从而尽早提供反馈。这也可能激励通常只参与涉及讨论的人员更多投入措辞组工作，从而提升委员会整体的措辞知识水平。此外，这种安排还将改善委员会在特定特性上的聚焦一致性。
总结
作为委员会，我们拥有共同的目标：维护一个既能为用户创造真实价值，又具备可实现性、高性能和可移植性的标准。我们的初衷是开启一系列建设性对话，探讨如何缩小标准化与实现之间的差距，以及希望看到改善早期沟通、提高成本与权衡的可见性，以及在采纳新特性和完善已有特性之间调整节奏与优先级等方面的讨论。
—— 完 ——