Andrew Kelley 踩的那条线

前几天晚上翻 issue 刷到 Andrew Kelley 提的东西——给 Zig 加一个 fil ABI 编译模式，全量内存安全。我一开始以为是又往安全上靠了，往下读完才发现他踩的是一条很有意思的线。

先停一下，问个问题：为什么是 ABI，不是 language feature？

因为内存安全最大的敌人不是你自己写的代码，是你的依赖树。你在 Zig 里写得再干净，链了一个没做检查的 C 库，全白搭。语言层面的检查管不到 C 代码，但 ABI 层面可以——只要强制所有链接进来的东西都用 fil 编译，linker 直接拒掉不兼容的 object，就没漏网的。

然后 issue 里就吵。Fil-C 的 invisicaps 会在"不该分配的地方"搞隐藏分配，跟 Zig "分配必须显式"的哲学直接打架。alexrp 提的这条挺到位，但我更感兴趣的是 Andrew 在 proposal 标题里专门挑出来强调的那句话：no escape hatches like in Rust。

Rust 的安全模型有一个设计上的出口：unsafe。你需要跟硬件打交道、写 FFI、做底层操作，硬堵死语言没法用。这个设计是对的——但 Andrew 想要的是另一种东西。

fil ABI 下没有 unsafe，没有 escape hatch，连 C 依赖一起绑死在安全模式里。拿一个没编译成 fil 的 C 库进来，linker 直接拍回去。

Rust 给你一把带保险的枪——保险开着安全，需要时可以关。fil ABI 给你一个焊死的笼子——绝对安全，也没法绕了。

Fil-C 的作者 Filip Pizło 也跑来参与了讨论，给了挺务实的建议：把 ABI 冻住，别对非 C 指针用 invisicaps，别吃 GC 的开销。Andrew 的绕法是不照搬 Fil-C 的 GC，往 metadata 里塞 unique type ID——use-after-free 之后不会 type confusion，而这些 ID 本来做 pointer-cast 检查就需要。

我一开始觉得这事气质上跟 Zig 不搭——一直主打显式控制，突然加一层用户看不见的运行时插桩。后来换了个角度：Debug、ReleaseFast、ReleaseSafe 都还在，fil 只是额外的 ABI 选项。你不想用就不用。这是个加法不是替换。

所以 Andrew 真正挑战的不是 Rust 的安全性。Rust 把线画在"大多数时候安全，偶尔可以不安全"。他在试：能不能把线画在"永远安全，代价是你不能不安全"。代价是 1-6x 的性能惩罚、所有 C 库重新编译、目前只有 x86_64-linux。

他在赌有一批人愿意接这个。

再往下就是安全跟灵活的边界该划在哪了，这个我还没想明白，先放这儿。