rust - 不安全指定生命周期的例子有哪些?

标签 rust lifetime

<分区>

过去三天我一直在学习生命周期主题,现在我开始理解它们了。然而,我做了很多实验,但没有设法以导致运行时不安全行为的方式指定生命周期,因为编译器似乎足够聪明,可以防止这种情况发生,通过不编译。 因此,我有以下问题链:

Rust 编译器真的会捕获所有不安全的生命周期说明符使用情况吗?

  • 如果是,那么为什么 Rust 需要手动指定生命周期,而它可以通过推断不安全的场景自行完成?或者它只是一个遗物,一旦编译器变得足够强大,可以在任何地方进行生命周期省略,它就会消失?
  • 如果不是,不安全生命周期说明符用法的示例是什么?他们会清楚地证明手动指定生命周期的必要性。

最佳答案

除非您使用不安全的代码(在函数中或其他地方),否则不可能(除非有任何编译器错误)通过生命周期说明符引发未定义的行为。但是,生命周期说明符仍然是必需的,因为有时对于正确的生命周期应该是什么存在歧义。例如:

fn foo(bar: &i32, baz: &i32) -> &i32 {
    // ...
}

返回类型的生命周期应该是多长?编译器无法推断出这一点,因为它可能与 barbaz 相关联,并且每种情况都会影响返回值的持续时间以及函数的使用方式。函数体不能用于推断生命周期,因为类型和生命周期检查必须能够仅使用函数的签名来完成。消除这种歧义的唯一方法是明确说明返回值应具有的生命周期:

fn foo<'a>(bar: &i32, baz: &'a i32) -> &'a i32 {
    // ...
}

您可以阅读有关生命周期省略规则的更多信息 here .

关于rust - 不安全指定生命周期的例子有哪些?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58887620/

相关文章:

rust - 构建 Rocket handlebars 示例时 Unresolved 导入模板

rust - 是否可以查看当前安装的 Rust 版本的源代码?

testing - 为什么Rust在循环后重置一些变量?

rust - 收集到矩阵中的清洁方式

rust - 使结构比赋予该结构的方法的参数更长寿

performance - 为什么选择 `unwrap_or_else` 而不是 `unwrap_or` ?

rust - 线程之间共享引用的生命周期问题

rust - 递归类型-生命周期问题

rust - 是否有一种惯用的方法来保持对不断增长的容器元素的引用?

generics - 如何在Rust中实现装饰器?