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