21CTO导读：由于对一项增强安全性的合约（亦称契约，Contracts）功能存在争议，C++ 程序设计语言的下一个版本大概会在最后一刻被推迟发布。 

合约机制在C++的技术维护者中引发了严重分歧。

一方支持C++之创始人比雅尼·斯特劳斯特鲁普（Bjarne Stroustrup ），他反对目前形式的合约机制，理由是该机制仓促实现。但是，另一方则渴望看到合约机制的实施，甚至认为该机制的反对者正在毒害C++的开发过程本身。 

就在投票批准新版语言之前，双方的分歧彻底爆发了。 

10 月，C++26 的国际标准草案 (DIS) 在 ISO 投票中失败——这是国际标准化组织批准过程中的倒数第二个阶段，在此阶段，标准的技术细节将由一组国家标准机构正式批准。

投票结果为13票赞成，9票反对，12票弃权，未能满足ISO规定的反对票不超过25%的要求。合同问题是投反对票者的主要顾虑。 

什么是合约纠纷

合约或称契约允许开发者在代码中添加前提条件和后置条件，以及用于检查指定条件是否成立的断言。这些检查有助于发现可能导致未定义行为的编程错误。

契约式设计一直是Ada和Eiffel等程序设计语言的特点。

至少十年来，开发者们一直提议将合约添加到 C++ 中，此前由于担心默认值存在危险，合约突然从 C++20 中 被移除。

但 Stroustrup 对最终被纳入 C++26 的  修订提案 ( P2900 ) 进行了猛烈抨击。

Stroustrup 和他的同事在去年八月的一篇论文中写道： “P2900 合约和扩展旨在改变 C++ 的本质，对 C++ 构成生存威胁，增加了复杂性和臃肿性。” 

他们指出，目前的实现混乱、过时、未经充分测试，如果以库的形式实现会更有效。

并非所有人都同意这一观点。C  ++标准化委员会成员Andreas Fertig认为，这些批评意见已经过审查，在C++发布流程的后期否决该提案对C++本身是有害的。

“这个议题已经讨论了多年，并且以目前的形式多次获得多数票通过。投‘反对票’动摇了一个建立在信任和相互尊重的合作基础上的既有体系，”费尔蒂格在一篇博客文章中写道。

当然，最显而易见的问题在于，人们一直批评C++ 很容易让开发者无意中创建安全漏洞，这导致不少项目转而采用 Rust。正如 Stroustrup 指出的那样，添加控制措施可能会削弱 C++ 的主要优势——极快的开发速度。 

输不起的人员

费尔蒂格指责斯特劳斯特鲁普等人输不起。

他写道：“每一项ISO标准都不过是一系列妥协的产物。每个人都会有输赢的时候。” 但在这个案例中，“失败的一方拒绝接受失败。决定未来走向的关键问题在于，该组织能否重建信任。”

与 Fertig 不同，维护开源 EDG  C++ 编译器前端的C++ 联盟首席执行官 Harry Bott认为，关于合约的讨论不会对 C++ 本身造成破坏。

“退回的草案并非流程的失败——而是流程按预期运行的体现，”他通过电子邮件告诉《The Register》。“但这并不意味着流程不能改进。我们的目标应该是从中吸取教训，加强流程，以便C++能够以开发者可以信赖的方式继续发展。” 

接下来该去哪里？

由于投票在标准化流程的后期阶段失败——这在 C++ 历史上实属罕见——该语言有可能错过今年的预期发布日期。这一结果可能迫使大家将新版本称为“C++27”而不是 C++26。（这只是一个非正式名称；如果明年发布，该语言的第八个版本的正式名称将是“ISO/IEC 14882:2027”。）

ISO C++ 工作组WG21将于下周在巴西布济奥斯 举行会议，进行最终辩论。

根据巴黎Margo 咨询公司软件工程顾问 Thibault Ricord-Marchal 的一篇博客文章，该集团面临着许多选择。 

他们可以把合约（Contracts）从规范中剔除，这样 C++26 的其他部分就可以顺利发布了。但这会是一项繁琐的工作。很多已经使用合约进行库加固的工作都需要撤销。

另一种选择是将合同移至单独的技术规范中，以便继续改进技术。 

或者人们可以坐下来稍作修改，再次投票。然后，寄希望于巴西温暖宜人的天气，或者能让大家平静下来。

作者：洛逸