I want extern "fil-c"

我想要 extern "fil-c" 来源：https://domenkozar.com/2026/08/13/i-want-extern-fil-c/ Rust 的 C FFI 让我们能访问数十年积累的有用软件，但这笔交易的代价是反过来的。 我们用 Rust 在编译期证明内存安全。然后跨过 `unsafe` 边界，信任 C 库遵守一份两种语言都无法强制执行的契约。遗留代码仍然是廉价路径，而重写它是昂贵路径。 Fil-C (https://fil-c.org/) 提供了一种更有意思的交易。它用 capability、运行时检查，以及并发垃圾回收器重新编译 C 和 C++。内存安全违规会变成 panic，而不会变成可利用漏洞。现有软件通常只需要很少甚至不需要修改源码，但要在运行时为安全付出代价。 我想要一个讲 Fil-C ABI 的 Rust FFI。 第一个版本可以故意做得很窄：标量值、拷贝的字符串和切片，以及不透明句柄。它会生成安全的 Rust 包装器，用 Fil-C 编译完整的 C 依赖图，并且不提供任何逃回普通不安全 C 的逃生舱。共享内存可以以后再支持，只要这座桥能让 Fil-C 获得一个 Rust 可以可靠撤销的 capability。 这并不是 `bindgen` 的一个新选项。Fil-C 与 C 源码兼容，但刻意在 ABI 上不兼容 (https://fil-c.org/runtime)，而普通 Rust `extern "C"` 讲的是 Fil-C 称为 Yolo-C 的 ABI。构建这座桥意味着教会 Rust、Fil-C，或一对生成的桩代码，如何在不会丢失 Fil-C 保证的前提下交换值。如果这件事很容易，它早就存在了。 这个技术栈中一个重要部分已经在成形。filnix (https://github.com/mbrock/filnix) 将 Fil-C 打包为 Nix 交叉编译平台，并且已经有 100 多个 nixpkgs 包的移植。把 Fil-C 当作一个平台，意味着 Nix 会为 Fil-C ABI 重建传递依赖闭包，而不是意外把普通 C 链接进去。filnix 还不是 Rust 桥，但它提供了可复现的工具链、包宇宙和测试床，在那里可以构建这样一座桥。 Zig 正从另一个方向接近同一个问题。Andrew Kelley 提出了一个受 Fil-C 启发的可选 `fil` ABI (https://codeberg.org/ziglang/zig/issues/36237)。它会是 Zig 编译器和标准库中的一个独立实现，旨在用运行时内存安全来编译一个 Zig 程序及其整个 C 和 C++ 依赖树。这与 Rust 桥需要进入的世界已经非常接近了。 但结果会给我们带来完全正确的激励。 我们可以用 Rust 获得编译期安全，然后为使用 C 而付出性能代价。 保留遗留库，它仍然是内存安全的，但每次指针操作都会被检查，其内存也参与垃圾回收。用 Rust 重写热路径后，这些检查变成静态检查，因此开销消失了。C 变成了安全兼容路径，而不再是永久的快速路径。 这里的“100% 安全”是指在整个受支持边界内内存安全，而不是没有逻辑错误、死锁或糟糕的 API。这个边界才是难点。Fil-C 目前要求整个程序和它的依赖都使用其 ABI (https://fil-c.org/runtime)。该项目还把与普通 C 的互操作视为非目标。Rust 桥必须保持这种整体世界保证，而不是悄悄在中间打出一个 Yolo 形状的洞。 我想要 `extern "fil-c"`：Rust 在快速路径上，旧 C 在安全路径上，并有一个性能上的理由去完成迁移。 我还希望看到跨生态系统的协作，而不是几个几乎兼容的孤岛。Fil-C 拥有 capability 模型和可运行的运行时。Rust 拥有编译期安全。Zig 正在探索一个受 Fil-C 启发的 ABI。Nix 和 filnix 可以重建并测试完整的依赖图。这个问题值得四个社区最优秀的人才坐在同一个房间里。 所以，这里就是邀请：明年加入我们在兰萨罗特岛举办的 OceanSprint (https://oceansprint.org/)，一起把它构建出来。正在构建 filnix 的 Mikael Brockman 已经接受了邀请。 还有谁要加入我们？