代码之家 › 专栏 › 技术社区 › typesanitizer

为什么铁锈有一种“永不”的原始类型?

rust types

typesanitizer · 技术社区 · 7 年前

std::process::exit 具有类型

pub fn exit(code: i32) -> !

! 是 "Never" primitive type .

将此与Haskell进行比较,其中 System.Exit.exitWith 是

exitWith :: forall a. Int -> a

相应的锈迹特征是

pub fn exit<T>(code: i32) -> T

T 因为 T型 从未实现,因此编译仍应有效。

2 回复 | 直到 7 年前

Shepmaster Tim Diekmann 7 年前

因为它支持局部推理和可组合性。

你的替换想法 exit() -> ! exit<T>() -> T 只考虑类型系统和类型推理。从类型推理的角度来看,两者都是等价的,这是对的。然而,语言不仅仅是类型系统。

无意义码的局部推理

出席 ! 允许本地推理检测无意义代码。例如,考虑:

use std::process::exit;

fn main() {
    exit(3);
    println!("Hello, World");
}

编译器立即标记 println! 声明:

warning: unreachable statement
 --> src/main.rs:5:5
  |
5 |     println!("Hello, World");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unreachable_code)] on by default
  = note: this error originates in a macro outside of the current crate
          (in Nightly builds, run with -Z external-macro-backtrace for more info)

exit 的签名表明它将永远不会返回,因为 !

优化的局部推理

出口 到LLVM优化器。

在宣言中第一个 出口 :

; std::process::exit
; Function Attrs: noreturn
declare void @_ZN3std7process4exit17hcc1d690c14e39344E(i32) unnamed_addr #5

; playground::main
; Function Attrs: uwtable
define internal void @_ZN10playground4main17h9905b07d863859afE() unnamed_addr #0 !dbg !106 {
start:
; call std::process::exit
  call void @_ZN3std7process4exit17hcc1d690c14e39344E(i32 3), !dbg !108
  unreachable, !dbg !108
}

可组合性

在C++中, [[noreturn]] 是一种属性。这真是不幸,因为它没有与泛型代码集成:对于 noreturn 诺雷顿 类型是多种多样的,因为有图书馆使用一个。

生锈了, 是一个一流的构造,所有库都是统一的,最棒的是。。。即使没有 !

最好的例子是 Result 类型(Haskell's Either Result<T, E> 哪里 T 是预期的类型和 E 错误类型。没有什么特别的 ! 结果 ,但它可以用 ! :

#![feature(never_type)]

fn doit() -> Result<i32, !> { Ok(3) }

fn main() {
    doit().err().unwrap();
    println!("Hello, World");
}

编译器可以看穿它:

warning: unreachable statement
 --> src/main.rs:7:5
  |
7 |     println!("Hello, World");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unreachable_code)] on by default
  = note: this error originates in a macro outside of the current crate
          (in Nightly builds, run with -Z external-macro-backtrace for more info)

对不能实例化的类型进行推理的能力也扩展到对不能实例化的枚举变量的推理。

例如,以下程序编译:

#![feature(never_type, exhaustive_patterns)]

fn doit() -> Result<i32, !> {
    Ok(3)
}

fn main() {
    match doit() {
        Ok(v) => println!("{}", v),
        // No Err needed
    }

    // `Ok` is the only possible variant
    let Ok(v) = doit();
    println!("{}", v);
}

通常情况下, 有两种变体: Ok(T) Err(E) ,因此匹配必须同时考虑这两个变体。

然而,自从无法实例化, Err(!) 不可能,因此 Result<T, !> 只有一个变体: . 因此,编译器只允许考虑 Ok 案例。

编程语言不仅仅是它的类型系统。

意图给其他开发者和机器。Never类型使开发人员的意图变得清晰,允许其他方清楚地理解开发人员的意思,而不必从偶然的线索重建意思。

trent oli_obk 7 年前

! 包括:

表面语言无法提供任何写作方式 type Never = for<T>(T) type Never = forall a. a 在哈斯克尔。

更一般地,在类型别名中,如果不在RHS上引入类型变量(也称为泛型参数),就不能在RHS上使用它们 ,这正是我们想在这里做的。使用空的struct/enum没有意义,因为我们希望这里有一个类型别名,以便 Never 可以统一为任何类型,而不是新构造的数据类型。

由于此类型不能由用户定义,因此它提供了将其添加为原语可能有意义的一个原因。
如果一个在语法上被允许给RHS分配一个非单组织类型(比如 forall a. a ),编译器将需要任意选择w.r.t.调用约定(正如trentcl在注释中指出的那样),即使选择并不真正重要。Haskell和OCaml可以回避这个问题,因为它们使用统一的内存表示。