Safe C++提案旨在为C++添加一个安全子集，提供类似Rust的内存、类型和线程安全保证，同时不破坏现有代码。该提案允许开发者选择性地标记安全代码，未标记部分仍保持C++原有的“不安全”特性。尽管提案在解决C++安全性问题上具有潜力，但由于存在未解决的问题，该提案目前未被继续推进。

Safe C++提案不再继续推进

一年前，Safe C++提案被提出，旨在为C++引入一个安全的子集或上下文，提供类似于Rust的内存安全、类型安全和线程安全等强保证，同时不破坏现有的C++代码。该提案是C++的扩展或超集，通过显式标记代码中的安全上下文来实现选择性加入。提案作者甚至表示：

安全上下文中的代码表现出与Rust代码相同的强安全保证。

其余部分则保持C++原有的“不安全”特性。这意味着现有代码可以继续运行，而新代码或重构部分可以获得更高的安全性。对于熟悉Rust的开发者来说，Safe C++与Rust有许多相似之处，尽管为了适应C++的设计进行了一些调整。此外，由于C++已经拥有庞大的“不安全代码”基础，Safe C++必须提供机制来混合安全和不安全代码，并支持逐步迁移。因此，Safe C++的所有安全特性都是可选的，现有代码可以像以前一样编译和运行，引入安全上下文不会破坏未使用它的代码。

该提案引起了我的兴趣，尽管它仍存在一些未解决的问题（这在草案提案中是完全正常的），但它似乎是一个使C++更安全的良好折中方案。例如，借用检查器和生命周期错误的错误报告机制，以及泛型代码和模板如何与生命周期逻辑和安全/不安全限定符交互等问题。然而，今天我发现该提案将不再继续推进。当我再次思考该提案时，意识到已经有一段时间没有看到相关更新，于是我在Reddit上找到了一些答案。

Safe C++提案的原作者之一Sean Baxter回应道：

安全与安全工作组投票决定优先考虑Profiles而非Safe C++。请向Profiles团队询问更新。Safe C++不再继续推进。

他进一步解释：

Rust的安全模型在委员会中不受欢迎。我继续努力也无法改变这一点。Profiles赢得了争论。所有努力都应集中在将Profiles的语言特性纳入标准中，以消除悬空指针、数据竞争、死锁和资源泄漏等问题，使开发者能够从中受益。

于是，我阅读了与Profiles相关的文档[1][2][3][4]，并尝试总结其核心思想：Profiles旨在定义C++的模式，通过对语言和库的使用施加约束来保证某些安全属性。这些约束主要是编译时的，尽管在实践中某些检查可能会通过库设施实现，带来有限的运行时开销。与引入全新语言构造不同，Profiles主要限制现有特性和用法。开发者可以选择启用某个Profile，启用后代码必须遵循其限制，否则代码将像以前一样运行，因此它是向后兼容的。

Profiles看起来更为温和且更易采用，是一种默认更安全的C++，而不强制引入Rust模型。相比之下，Safe C++更为雄心勃勃，引入了新语法、类型限定符、安全与不安全上下文等。委员会中有人认为这过于复杂，而Profiles被视为更务实的路径。主要反对意见显而易见：Profiles的限制可能不如Safe C++提供的那么全面。

从社区中的评论来看，人们对采用Rust模型存在明显的抵触情绪。从某种角度来看，这种抵触是可以理解的：如果你想写Rust风格的代码，直接使用Rust即可。历史上，C++经常从其他语言中借鉴特性并将其整合到自身中。在这种情况下，我认为C++的安全子集在某种程度上已经非正式地存在。Profiles试图标准化和统一实践中已经存在的东西，它们并没有引入新的基本语义，而是提供了约束、义务和保证。

在我看来，考虑到委员会和整个C++社区的偏好，尽管我欣赏Safe C++提案并期待看到具体成果，但考虑到C++的实际情况，我认为标准化和整合Profiles是一个更为现实的方法。Profiles可能并不完美，但它们总比没有好。它们在执行上可能不均衡，原则上也可能比Safe C++弱，但它们是一个现实的前进方向。

评论主要围绕C++的安全性改进展开，观点分为支持和批评两派。

支持C++安全性改进的观点： 1. C++仍在努力提升安全性：尽管Sean Baxter的提案未被继续，但委员会仍在推进Profiles提案，这将在一定程度上提升安全性。 - "C++ is still working towards safety, just not the Safe C++ safety."（C++仍在努力提升安全性，只是不是通过Safe C++的方式。） - "the committee is working on the Profiles proposal, which still will enable some level of safety."（委员会正在推进Profiles提案，这仍将带来一定程度的安全性。）

2. 技术改进的可能性：有人认为可以通过编译器指令（如#pragma pointer_safety strong）来强制使用智能指针，从而提升安全性。
   • "wouldn't it be straightforward to do something like #pragma pointer_safety strong which would force the compiler to only accept the use of smart pointers."（是否可以通过类似#pragma pointer_safety strong的指令强制编译器只接受智能指针的使用。）

批评C++安全性改进的观点： 1. Profiles提案的局限性：Profiles提案无法达到Rust的安全水平，因为它只是删除了语言中的某些功能，而没有引入类型系统来精确表达语义。 - "Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes."（Profiles无法达到Rust的安全水平，这对任何人来说都是显而易见的。） - "Without lifetimes reified as types you can't express semantics with precision enough to check them."（如果没有将生命周期具体化为类型，就无法精确表达语义以进行检查。）

2. 文化问题：C++缺乏Rust那样的安全文化，这是其安全性改进的主要障碍。

   • "the big thing Rust has that C++ does not is safety culture, and that's dominant here."（Rust拥有而C++缺乏的是安全文化，这是主导因素。）
   • "this isn't likely to change any time soon."（这种情况短期内不太可能改变。）

3. C++的C根源问题：只要C++保留其C语言的根源，它就永远不会真正安全。

   • "C++ will never be safe as long as its C root persists."（只要C++保留其C语言的根源，它就永远不会真正安全。）
   • "You need to take off the 'inherently unsafe' C root from C++."（你需要从C++中去除“本质上不安全”的C根源。）

4. 对内存安全的态度：C++委员会中的大多数人认为内存安全只是炒作，少数人知道这是个问题，但不愿意在编码上限制自己。

   • "Majority of them believes that memory safety is just hype."（他们中的大多数人认为内存安全只是炒作。）
   • "minority of them knows it's a problem, but doesn't want to restrict themselves about coding."（少数人知道这是个问题，但不愿意在编码上限制自己。）

总结：C++在安全性改进方面存在分歧，支持者认为Profiles提案和技术改进可以提升安全性，而批评者则认为Profiles提案的局限性、文化问题和C++的C根源使其无法达到Rust的安全水平。