Primitive Type never[−]
Expand description
! 类型,也称为 “never”。
! 表示永远无法解析为任何值的计算类型。
例如,exit 函数 fn exit(code: i32) -> ! 退出该进程而不返回,因此返回 !。
break, continue 和 return 表达式也具有 ! 类型。例如,我们可以写:
#![feature(never_type)] let x: ! = { return 123 };Run
尽管 let 在这里毫无意义,但它说明了 ! 的含义。由于从未给 x 赋值 (因为 return 从整个函数返回),因此可以给 x 指定 ! 类型。我们也可以将 return 123 替换为 panic! 或永无休止的 loop,并且此代码仍然有效。
以下代码更实际地使用 !:
let num: u32 = match get_a_number() { Some(num) => num, None => break, };Run
两个匹配分支都必须产生 u32 类型的值,但是由于 break 根本不会产生值,我们知道它永远不会产生不是 u32 的值。这说明了 ! 类型的另一种行为 - 类型为 ! 的表达式将强制转换为任何其他类型。
! 和泛型
绝对的错误
您将看到显式使用的 ! 的主要位置是泛型代码。考虑 FromStr trait:
trait FromStr: Sized { type Err; fn from_str(s: &str) -> Result<Self, Self::Err>; }Run
当为 String 实现此 trait 时,我们需要为 Err 选择一个类型。并且由于将字符串转换为字符串永远不会导致错误,因此适当的类型是 !。
(当前实际使用的类型是一个没有成员的枚举,尽管这只是因为 ! 以后才会被添加到 Rust 中,并且将来可能会发生变化。) 对于 Err 类型的 !,如果我们由于某种原因不得不调用 String::from_str,那么结果将是 Result<String, !>,我们可以像这样解包:
#![feature(exhaustive_patterns)] use std::str::FromStr; let Ok(s) = String::from_str("hello");Run
由于 Err 成员包含 !,因此永远不会发生。如果存在 exhaustive_patterns 功能,则意味着我们只需采用 Ok 成员就可以在 Result<T, !> 上进行全面匹配。
这说明了 ! 的另一种行为 - 它可以用于 “delete” 泛型 (如 Result) 中的某些枚举成员。
无限循环
尽管 Result<T, !> 对于消除错误非常有用,但 ! 也可以用于消除成功。如果我们将 Result<T, !> 视为 “if this function returns, it has not errored,”,那么我们也会非常直观地想到 Result<!, E>: 如果函数返回,则 有 错误。
例如,考虑一个简单的 Web 服务器的情况,它可以简化为:
loop { let (client, request) = get_request().expect("disconnected"); let response = request.process(); response.send(client); }Run
目前,这并不理想,因为只要无法建立新的连接,我们就简单地使用 panic。 相反,我们想跟踪此错误,如下所示:
loop { match get_request() { Err(err) => break err, Ok((client, request)) => { let response = request.process(); response.send(client); }, } }Run
现在,当服务器断开连接时,我们以错误退出循环而不是恐慌。虽然简单地返回错误可能很直观,但我们可能希望将其包装在 Result<!, E> 中:
fn server_loop() -> Result<!, ConnectionError> { loop { let (client, request) = get_request()?; let response = request.process(); response.send(client); } }Run
现在,我们可以使用 ? 代替 match,并且返回类型更有意义: 如果循环停止,则意味着发生了错误。我们甚至不必将循环包装在 Ok 中,因为 ! 会自动强制转换为 Result<!, ConnectionError>。
! 和 traits
编写自己的 traits 时,只要有明显的 impl 而不是 panic!,! 就应该有一个 impl。原因是返回 impl Trait 且 ! 没有 impl 的函数不能作为它的唯一可能的代码路径发散。
换句话说,它们不能从每个代码路径返回 !。
例如,此代码不会编译:
use std::ops::Add; fn foo() -> impl Add<u32> { unimplemented!() }Run
但是这段代码可以做到:
use std::ops::Add; fn foo() -> impl Add<u32> { if true { unimplemented!() } else { 0 } }Run
原因是,在第一个示例中,! 可以强制转换为许多可能的类型,因为许多类型实现了 Add<u32>。
但是,在第二个示例中,else 分支返回 0,编译器从返回类型推断出它为 u32 类型。由于 u32 是具体类型,因此 ! 可以并且将被强制使用。有关此 ! 的更多信息,请参见问题 #36375。
但是,事实证明,大多数 traits 都可以将 impl 用作 !。以 Debug 为例:
#![feature(never_type)] impl Debug for ! { fn fmt(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result { *self } }Run
我们再次使用 ! 的功能来强制转换为任何其他类型,在本例中为 fmt::Result。由于此方法将 &! 作为参数,因此我们知道它永远不能被调用 (因为没有 ! 类型的值可以调用它)。
编写 *self 实质上就是告诉编译器 “We know that this code can never be run, so just treat the entire function body as having type fmt::Result”。
当为 ! 实现 traits 时,可以使用这种模式。
通常,任何仅具有采用 self 参数的方法的 trait 都应具有这样的含义。
另一方面,不适合实现的一个 trait 是 Default:
trait Default { fn default() -> Self; }Run
由于 ! 没有值,因此也没有默认值。的确,我们可以为此编写一个 impl,它只是 panics,但是对于任何类型都一样 (我们可以通过仅将 default() panic 制作为 (eg.) File 来使用 impl Default)。