一项旨在为 C++ 引入类似 Rust 的内存、类型和线程安全保证的 “Safe C++” 提案已被搁置。C++ 委员会转而支持名为 “Profiles” 的替代方案。Profiles 通过限制现有 C++ 功能的使用来提供安全保障，被认为是一种更务实、更易于采纳的方法。尽管其安全强度可能不如最初的 Safe C++ 设想，但它代表了一条在 C++ 生态中更具现实意义的改进路径。
“Safe C++” 提案的目标
“Safe C++” 提案旨在为 C++ 语言引入一个可选的 “安全上下文”。其核心目标是提供与 Rust 语言相媲美的强大安全保证，同时不破坏现有代码的兼容性。
- 核心保证: 致力于实现 内存安全、类型安全和线程安全。
- 工作方式: 开发者可以明确地将部分代码标记为“安全”，使其遵循更严格的编译规则。未标记的代码则继续按传统的 C++ 方式工作。
- 设计哲学: 它被设计为 C++ 的一个 扩展或超集，允许新编写或重构的安全代码与庞大的现有“不安全”代码库共存，并支持渐进式迁移。
提案被搁置的原因
尽管 Safe C++ 提案看起来是一个理想的折衷方案，但它最终未能继续推进。该提案的作者之一 Sean Baxter 明确指出了原因：
C++ 安全与保障工作组投票决定优先考虑 Profiles 而非 Safe C++。……Rust 的安全模型在委员会中并不受欢迎。Profiles 赢得了争论。
简而言之，委员会认为引入一个类似 Rust 的全新安全模型过于激进，转而选择了一个他们认为更温和、更符合 C++ 演进传统的方案。
替代方案：“Profiles”
“Profiles” 是委员会选择的替代方案，它采取了与 Safe C++ 截然不同的路径来实现代码安全。
- 核心理念: Profiles 并非引入新语法或新功能，而是定义了 C++ 的一种 受限模式。
- 实现方式: 它通过对现有语言和库的用法施加 约束 来保证安全。这些主要是编译时检查，目的是消除最常见的 C++ 陷阱，如悬垂指针和数据竞争。
- 向后兼容: 开发者可以选择启用某个 Profile。遵循其约束的代码将获得相应的安全保证，而未启用 Profile 的代码则完全不受影响。
更务实，但或许不够彻底
社区中对于完全采纳 Rust 模型的做法存在明显的抵触情绪，一种普遍的观点是：“如果你想写 Rust 风格的代码，那就直接用 Rust。” 从这个角度看，Profiles 方案的胜出并不意外。
- Safe C++ 的雄心: 引入新语法、类型限定符和安全/不安全上下文，是一次 激进的变革。
- Profiles 的务实: 被视为一种 更实用、更易于被社区接纳 的方法。它更像是在标准化和统一那些已经在实践中存在的非正式安全子集。
- 最终的权衡: 尽管 Safe C++ 的设想更美好，但考虑到委员会和整个 C++ 社区的偏好，Profiles 是一条 更加现实的前进道路。它们可能不是完美的“银弹”，提供的安全保证也不如 Safe C++ 强大，但有总比没有好。