Início / coding / Perguntas / 78541557
Accepted
Some Name
Asked: 2024-05-28 09:08:03 +0800 CST

Atribuir o parâmetro do método RefCell a uma variável local produz erro de compilação

  • 772

Considere o seguinte exemplo simples:

use std::cell::RefCell;

// Compiles fine
fn good(t: RefCell<String>) -> bool {
    t.borrow().len() == 12
}

// error[E0597]: `t` does not live long enough
fn bad(t: RefCell<String>) -> bool {
    let t = t;
    t.borrow().len() == 12
}

Parque infantil

A badfunção falha ao compilar com o seguinte erro:

error[E0597]: `t` does not live long enough
  --> src/lib.rs:9:5
   |
8  |     let t = t;
   |         - binding `t` declared here
9  |     t.borrow().len() == 12
   |     ^---------
   |     |
   |     borrowed value does not live long enough
   |     a temporary with access to the borrow is created here ...
10 | }
   | -
   | |
   | `t` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `Ref<'_, String>`
   |
   = note: the temporary is part of an expression at the end of a block;
           consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
   |
9  |     let x = t.borrow().len() == 12; x
   |     +++++++                       +++

Isso parece extremamente estranho para mim. Apenas reatribuir o parâmetro de função a variáveis ​​locais falha na compilação. Você poderia explicar por quê?

rust

1 respostas

  1. Best Answer

    Isso é mencionado na Referência :

    Os temporários criados na expressão final de um corpo de função são eliminados após quaisquer variáveis ​​nomeadas vinculadas ao corpo da função. Seu escopo de eliminação é a função completa, já que não há um escopo temporário menor e envolvente.

    Não tenho certeza se isso é necessário para o funcionamento da linguagem, torna-a mais conveniente ou é simplesmente como o compilador foi originalmente implementado, mas seria incompatível com versões anteriores mudar agora. Se alguém souber mais, comente ou edite esta resposta.

    Estou ciente disso e às vezes surge ao entender a ordem de entrega. O que há de novo para mim é que os argumentos da função, aparentemente, são eliminados ainda mais tarde . Isso é quase mencionado aqui , mas não exatamente. A ordem de queda, portanto, deve ser:

    • Variáveis ​​criadas dentro da função
    • Temporários criados na expressão final
    • Argumentos de função

    Aqui está um programa que demonstra isso.

    struct A(u32);

impl A {
    fn nothing(&self) {}
}

impl Drop for A {
    fn drop(&mut self) {
        println!("drop {}", self.0);
    }
}

fn f(_a1: A) {
    let _a3 = A(3);
    A(2).nothing()
}

fn main() {
    let a = A(1);
    f(a);
}

    Ele imprime o seguinte:

    drop 3
drop 2
drop 1

    No seu código, a expressão final cria um arquivo std::cell::Ref<'_, String>. Como Reftem Dropcomportamento - especificamente, o tempo de vida está contido em um tipo que o implementa Drop- ele exige que o tempo de vida seja válido quando ocorre a queda, ao contrário de uma referência compartilhada normal &. Como ele toma emprestado do RefCell<String>, o Refdeve ser eliminado antes que o RefCellseja eliminado. E de acordo com as regras acima, isso não é satisfeito quando RefCellestá vinculado à função.

    A solução alternativa na mensagem de erro sempre deve ser suficiente.

    • 5

relate perguntas