Как написать правильную сигнатуру обобщенной функции при заимствовании данных по нескольким признакам - PullRequest
0 голосов
/ 18 февраля 2019

При разработке частного проекта я столкнулся с пожизненной проблемой, связанной с заимствованием одного и того же объекта в нескольких структурах и особенностях.Вот несколько урезанных определений, которые я использовал:

trait WorkspaceLog {
    fn get(&self) -> usize;
}

struct TheLog<'a>(&'a FilesystemOverlay);

impl<'a> WorkspaceLog for TheLog<'a> {
    fn get(&self) -> usize {
        (self.0).0
    }
}

trait WorkspaceController<'a> {
    type Log: WorkspaceLog;
    fn get_log(&'a self) -> Self::Log;
}

struct FilesystemOverlay(usize);

struct FSWorkspaceController<'a>(&'a mut FilesystemOverlay);

impl<'a> WorkspaceController<'a> for FSWorkspaceController<'a> {
    type Log = TheLog<'a>;

    fn get_log(&'a self) -> Self::Log {
        TheLog(&*self.0)
    }
}

trait AsWorkspaceController<'a> {
    type Controller: WorkspaceController<'a>;

    fn get_controller(self) -> Self::Controller;
}

impl<'a> AsWorkspaceController<'a> for &'a mut FilesystemOverlay {
    type Controller = FSWorkspaceController<'a>;

    fn get_controller(self) -> FSWorkspaceController<'a> {
        FSWorkspaceController(self)
    }
}

Пока все хорошо.Это в основном позволяет мне заимствовать ссылку на FilesystemOverlay как некоторый другой интерфейс, предоставляя дополнительную функциональность.Этот интерфейс, в свою очередь, позволяет мне по существу заимствовать то же самое, что и еще одну вещь, которая предоставляет окончательные данные.Это работает до тех пор, пока я непосредственно использую FilesystemOverlay:

fn init1(control_dir: &mut FilesystemOverlay) -> usize {
    let controller = control_dir.get_controller();
    let log = controller.get_log();
    log.get()
}

Однако, если я заменю конкретную ссылку на параметр типа, компиляция завершится неудачно, сообщив мне, что контроллер не живет достаточно долго, так какпричины, которые я не понимаю, думает, что get_log занимает контроллер за пределами функции и, следовательно, намного дольше, чем требует логика программы:

fn init2<'a: 'b, 'b, O>(control_dir: O) -> usize
    where O: AsWorkspaceController<'b>+'a {
    let controller = control_dir.get_controller();
    let log = controller.get_log();
    log.get()
}

fn main() {
    let mut control_dir = FilesystemOverlay(5);
    dbg!(init1(&mut control_dir));
    dbg!(init2(&mut control_dir));
}

Я пробовал несколько подходов, но до сих пор не смог выяснитьправильная подпись init2.Это ошибка, которую я получаю:

error[E0597]: `controller` does not live long enough
  --> test.rs:53:15
   |
53 |     let log = controller.get_log();
   |               ^^^^^^^^^^ borrowed value does not live long enough
54 |     log.get()
55 | }
   | - borrowed value only lives until here
   |
note: borrowed value must be valid for the lifetime 'b as defined on the function body at 50:18...
  --> test.rs:50:18
   |
50 | fn init2<'a: 'b, 'b, O>(control_dir: O) -> usize
   |                  ^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0597`.

Это полный код ржавчины .

Итак, как мне нужно изменить подпись init2чтобы компилятор понимал, что контроллер может быть сброшен после вызова log.get ()?Нужны ли мне другие изменения в вышеперечисленных типах?

Редактировать: Я провел несколько дополнительных экспериментов, и это - самое близкое, что мне удалось создать.У этого есть два времени жизни и подпись, которая связывает поздно, но это все еще дает предупреждение о UB.Кто-нибудь понимает почему?

1 Ответ

0 голосов
/ 03 марта 2019

С помощью милого и знающего человека на GitHub я смог создать рабочую версию кода, см. https://github.com/rust-lang/rust/issues/58868. Ключом было использование свободного времени жизни, связанного с объявлением типа Controllerвнутри AsWorkspaceController:

trait AsWorkspaceController<'a> {
    type Controller: for<'b> WorkspaceController<'b>+'a;

    fn get_controller(&'a mut self) -> Self::Controller;
}

См. полный код на детской площадке .

...