为什么在同一范围内可能有多个具有静态生存期的可变引用

时间:2018-07-07 11:24:54

标签: static rust lifetime

为什么在同一个作用域中可以有多个对静态类型的可变引用?

My code

static mut CURSOR: Option<B> = None;

struct B {
    pub field: u16,
}

impl B {
    pub fn new(value: u16) -> B {
        B { field: value }
    }
}

struct A;

impl A {
    pub fn get_b(&mut self) -> &'static mut B {
        unsafe {
            match CURSOR {
                Some(ref mut cursor) => cursor,
                None => {
                    CURSOR= Some(B::new(10));
                    self.get_b()
                }
            }
        }
    }
}

fn main() {
    // first creation of A, get a mutable reference to b and change its field.
    let mut a = A {};
    let mut b = a.get_b();
    b.field = 15;
    println!("{}", b.field);

    // second creation of A, a the mutable reference to b and change its field.
    let mut a_1 = A {};
    let mut b_1 = a_1.get_b();
    b_1.field = 16;
    println!("{}", b_1.field);

    // Third creation of A, get a mutable reference to b and change its field.
    let mut a_2 = A {};
    let b_2 = a_2.get_b();
    b_2.field = 17;
    println!("{}", b_1.field);

    // now I can change them all
    b.field = 1;
    b_1.field = 2;
    b_2.field = 3;
}

我知道borrowing规则

  • 一个或多个对资源的引用(&T
  • 恰好是一个可变引用(&mut T)。

在上面的代码中,我有一个A方法的结构get_b(),用于返回对B的可变引用。有了这个参考,我就可以改变结构B的字段。

奇怪的是,可以在同一范围(b, b_1, b_2)中创建多个可变引用,而我可以使用它们全部来修改B

为什么我可以在'static中显示多个具有main()生存期的可变引用?

我试图解释这是行为的原因在于,因为我返回的生存期为'static的可变引用。每次我调用get_b()时,它都会返回相同的可变引用。最后,它只是一个相同的参考。这个想法对吗?为什么我可以单独使用从get_b()获得的所有可变引用?

1 个答案:

答案 0 :(得分:8)

唯一的原因是 您对编译器撒谎了。您正在滥用unsafe代码,并且违反了Rust关于可变别名的核心原则。您声明自己了解借用规则,但随后竭尽全力破坏借用规则

unsafe代码为您提供a small set of extra abilities,但作为交换,您现在有责任避免使用每种可能的undefined behavior。多个可变别名是未定义的行为。

涉及static的事实与问题完全正交。您可以在任何生命周期内创建对任何事物(或没有任何事物)的多个可变引用:

fn foo() -> (&'static i32, &'static i32, &'static i32) {
    let somewhere = 0x42 as *mut i32;
    unsafe { (&*somewhere, &*somewhere, &*somewhere) }
}

在您的原始代码中,您声明调用get_b对于任何人都可以执行多次。这不是真的。整个功能应标记为不安全,并附有大量有关防止和禁止触发不安全内容的文档。然后,任何unsafe块都应具有相应的注释,以解释为什么那个特定用法不会违反所需的规则。所有这些使创建和使用unsafe代码比安全代码更加乏味,但是与C的行在概念上是unsafe的C语言相比,它仍然要好得多。 / p>

仅当您比编译器了解得更多时,才应使用unsafe代码。在大多数情况下,对于大多数人来说,创建unsafe代码的理由很少。

the Firefox developers的具体提示:

zoomed in "this tall to use unsafe" sign zoomed out, showing sign is 8+ ft tall