Rust 的 never 类型终于稳定了
Stabilizing Rust's Never Type
Rust 语言中标志性的 never 类型（!）在经历两年多的打磨后，终于迎来了稳定版本。这一变化不仅让泛型代码能更高效地消除死分支，还统一了类型推断逻辑。然而，稳定化过程并非一帆风顺，它涉及了 Rust 2024 版中类型推断回退机制的微妙调整，从单位类型 () 变为 never 类型本身，这在技术上构成了破坏性变更。通过 crater 工具对 crates.io 上数百万个库的扫描，社区发现仅有极少数库真正受损，大部分问题可通过更新依赖或显式指定类型解决。此次更新标志着 Rust 在类型系统严谨性与实际工程效率之间迈出了关键一步，Infallible 类型也将正式成为 never 类型的别名。
这是一种由类型系统驱动的死代码消除形式，因为编译器知道任何声称拥有 never 类型值的代码实际上永远无法执行到那里。
HN 评论区
92- Georgelemental
> 多年来，标准库一直使用 `Infallible` 类型来规避 never 类型的不稳定状态。它的语义目的与 never 类型相同，但没有特殊的编译器支持。因此，使用它的代码虽然在技术上正确，但并非最优（例如枚举中多了一层标签，或产生死代码），因为优化器并不总能移除对 `Infallible` 的引用。
这不对。编译器一直将 `Infallible` 视为无人居住类型（uninhabited），并据此进行优化。缺乏编译器支持的缺点在于无法享受强制转换（coercions）带来的便利。（除此之外，这篇文章写得很好）
- xg15
> 在此更改之后（以及在 2024 版中），编译器会假设 T 应该是 !，而 ! 并不实现 Default 特质，从而导致编译错误。
如果 ! 可以强制转换为任何类型，为什么不把它视为实现了所有特质呢？
- cipherjim
我最喜欢的 never 类型能力是：当你需要实现一个返回 Result 的特质，但你的具体实现永远不可能产生错误时。
返回 Result<T, !>，编译器就会知道调用者永远不需要检查错误情况，因为根据定义它根本无法被构造出来。
- LatticeAnimal
对 Rust 开发者来说，用 "!" 代表 never 类型是显而易见的吗？我在 TypeScript 里经常用 "never"。我想象在 Rust 里也会频繁使用 never 类型。我觉得这里选一个更长、更人性化的名字会是更好的决定。（感觉这又增加了 Rust 的黑话，让语言更难学了）
- weinzierl
今年早些时候 RustWeek 上 Waffle 的相关演讲：
"When is never?"