C++委员会拒绝Rust风格安全模型提案

据提案联合作者透露，尽管内存安全问题持续引发担忧，C++标准委员会已放弃了一项旨在创建严格安全语言子集的详细提案。

"Rust安全模型在委员会中不受欢迎。我这边的进一步工作也不会改变这种情况。Profiles方案赢得了这场争论。"

"安全与安保工作组投票决定优先考虑Profiles而非Safe C++。如需最新进展，请咨询Profiles团队。Safe C++项目不会继续推进。"Sean Baxter在今年6月如是说。

当开发者如Simone Bellavia注意到该提案的周年纪念时，这个话题重新浮出水面。一年前，Baxter告诉The Reg，该项目将使C++开发者获得Rust级别的内存安全性，而无需学习新语言。"Safe C++防止用户编写不安全的代码，"他说，"这包括借用检查等编译时智能分析来防止释放后使用漏洞，以及用于类型安全的初始化分析。"

Safe C++支持代码的渐进式迁移，因为它只适用于安全上下文中的代码。现有的不安全代码将照常运行。

即使是提案是否被放弃这个问题本身也不够明确。C++委员会成员兼C++演进工作组(EWG)联合主席Erich Keane表示，Baxter的提案"获得了鼓励性投票，大约一半(20/45)的人支持Sean的论文，30/45的人支持Profiles工作(6人中立)...Sean完全可以继续这项工作，委员会中的许多人都希望看到他在标准化方面做出进一步努力。"

对此，Baxter回应道："Rust安全模型在委员会中不受欢迎。我这边的进一步工作不会改变这种情况。Profiles赢得了争论。"

他补充说，EWG采纳的语言演进原则包括"我们应该避免要求安全或纯函数注解，这种注解的语义是安全或纯函数只能调用其他安全或纯函数"。他表示，这是一个"不可调和的设计分歧。安全函数着色是Rust安全模型的核心"。

C++发明者Bjarne Stroustrup支持Profiles方案，他告诉我们，该方案的理念是："我希望获得这套保证，然后它将被强制执行。"据Stroustrup说，"令人遗憾的是，标准委员会感到困惑，没有保证这将包含在C++ 26中。"

话虽如此，Profiles方案同样备受争议，有人抱怨"Profiles看起来不像任何已建立的可行解决方案，没有实现，而且今年早些时候也未能进入C++ 26标准，委员会反而要求另一份白皮书"。

Baxter不相信Profiles能够实现目标。"如果Profiles有成功的机会，我会实现它。但它们永远不会成功。我在这里提供了许多失败原因的例子：https://www.circle-lang.org/draft-profiles.html，"他昨天在Hacker News上说。

他补充道："整个标准库都是不安全的。我提议了一个严格安全的std2，但被拒绝了。"

围绕如何让C++更安全的争议可能意味着转向不同的语言是更好的解决方案，无论是Rust，还是谷歌实验性的"C++继任者"Carbon项目等其他选择，后者的路线图显示可能在"2028年之后"发布1.0版本语言。

Q&A

Q1：Safe C++提案的核心功能是什么？

A：Safe C++是一个旨在创建严格安全C++语言子集的提案，其核心功能是防止用户编写不安全代码，包括借用检查等编译时智能分析来防止释放后使用漏洞，以及用于类型安全的初始化分析。它支持代码的渐进式迁移，只适用于安全上下文中的代码。

Q2：为什么C++委员会拒绝了Safe C++提案？

A：据提案作者Sean Baxter表示，Rust安全模型在委员会中不受欢迎。委员会在投票中选择优先考虑Profiles方案而非Safe C++。另外，委员会采纳的语言演进原则与Safe C++的安全函数着色机制存在不可调和的设计分歧。

Q3：Profiles方案与Safe C++有什么不同？

A：Profiles方案由C++发明者Bjarne Stroustrup支持，理念是"我希望获得这套保证，然后它将被强制执行"。但该方案同样备受争议，被批评不像任何已建立的可行解决方案，没有实现，且未能进入C++ 26标准。提案作者Baxter认为Profiles永远不会成功。