Rust 项目组本周把「Immobile types and guaranteed destructors」正式列入 2026-2027 路线图,状态标记为 Accepted,负责人是核心开发者 @lcnr。这个目标的实质,是给 Rust 类型系统加三个新的自动 trait——Move、Destruct、Forget,让一个类型可以声明自己"不能被移动"或"不能被 mem::forget 遗忘"。追踪入口分别是 rust-project-goals 仓库的 #635 和 rust 主仓库的 #149607,验证场景放在 Rust for Linux 内核项目里。
这不是一次简单的"加关键字"公告。Rust 从诞生起就假定所有类型都能被移动、能被无声遗忘,这两条假设写进了赋值语义和标准库 API。过去多年 Rust 靠 Pin 打补丁,但 Pin 把"不可移动"绑在引用位置上,而不是类型本身,Linux 内核团队为了绕开这套机制专门造了一整套 pin-init 基础设施。这次提案想把补丁拆掉,换成类型层面的显式声明,跟此前的 Sized hierarchy 走的是同一条路——那次拆掉的是"所有类型都有编译期已知大小"这条假设,才让 scalable vectors 能落地。
Pin 的老毛病,Move 想直接治
Async 里的自引用 future 是这次提案最直接的动机。一个状态机内部字段互相引用地址,一旦被移动,内部指针全废。Pin 靠"这个指针指向的东西不会动"来兜底,可构造阶段——对象还没被固定之前——地址依然可能变。这正是 Rust for Linux 团队早就吃过的"安全固定初始化问题":Pin 治的是"用的时候不能动",治不了"造的时候不能动"。
Move trait 把不可移动性直接挂在类型定义上:一个类型标了 !Move,从生到死都不能挪地址,构造期的漏洞随之消失。Forget 解决另一件事——mem::forget 目前对所有类型都安全,意味着析构函数随时可能被跳过。事务提交、作用域内的异步任务句柄,都需要"析构一定会跑"这个保证,!Forget 就是把这条保证写进类型系统。
"保证"两个字,别理解过头
标题里的 guaranteed destructors 容易让人以为析构函数天塌下来都会跑。实际边界小得多:这套机制只在 safe 代码的正常执行路径里生效,阻止你悄悄 move 或 forget 一个受保护的值。进程被 abort、发生硬件故障,或者代码本身写了 unsafe 绕过检查,析构函数照样可能不跑。这不是 Rust 独有的漏洞,而是任何语言层面的"保证"都绕不开的边界,但确实是这次提案里最容易被标题带偏的一点。
三条现有方案,三个不同问题
外界很容易把这次改动理解成"Rust 抄了 C++ 或 Swift 的移动语义",其实三者解决的不是同一件事。C++ 删掉拷贝/移动构造函数,解决的是所有权唯一性;Swift 的 ~Copyable 处理的也是这一层,不涉及地址是否稳定。Rust 现在的 Pin 和内核那套 pin-init,处理的是地址稳定性和析构时序,跟前两者是两个维度。这次 Move/Forget 提案要补的,恰恰是这两块——它不是在补所有权语义的洞,而是想把 Rust 自己那套补丁式的 Pin 方案,换成更干净的类型级表达。
Pin 治标,Move 想治本,但治本得先过内核这一关。
真正难啃的骨头在 async
作用域内安全生成异步任务,是这次提案反复提到的落地场景——句柄的析构函数负责 join 任务,只要句柄不能被 forget,join 就一定会发生。但这只解决了"析构会不会跑"的问题,没解决"跑的时候会遇到什么"。稳定版 Rust 到现在都没有通用的 AsyncDrop,析构函数不能 await,取消语义、跨 await 点的借用、字段销毁顺序这些更硬的问题都还悬着。Forget 更像是给这些问题铺地基,不是直接把它们解决掉。
工作项本身也留了空白:项目组明确写了,今年不碰 Future trait 本身的改动,理由是它是唯一依赖 Pin 的稳定 trait,牵一发动全身,得单独立项处理。即便 Move/Forget 落地,async 生态的库作者短期内也不会看到 API 层面的直接变化。
- 风险.async runtime 作者和依赖 mem::forget 语义做 FFI 的 unsafe 代码作者,需要重新检查自己的假设是否还站得住。
谁该盯这件事
Rust for Linux 团队是第一批要验证的对象,内核里那套为了绕开 Pin 时序漏洞而搭的 pin-init 基础设施,如果 Move trait 跑通,理论上能被简化甚至替换,具体要看 @BennoLossin 负责的内核测试结果。RFC 由 @yoshuawuyts 起草,编译器 MVP 由 @lcnr 和 @nia-e 推进,守擂设计探索的是 @nikomatsakis。2026-2027 只是探索性时间线,不是发布承诺——Sized hierarchy 当年也走了类似路径,牵动 trait 系统、借用检查、drop elaboration 好几个子系统,落地速度取决于 RFC 进度和编译器 MVP,两者目前都还没有公开的具体日期。