Как исправить «cannot infer an appropriate lifetime for lifetime parameter»?

Question

[tmshit]

Есть упрощенная версия проблемного кода.
При компиляции вылезает

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
  --> src/main.rs:58:18

Удалось это исправить, изменива трейт таким образом.
То есть в объявление трейта был добавлен анонимный лайфтайм

trait Encryptor {
    fn get_file(&self) -> Box<dyn File + '_>;
}

, а в имплементации был добавлен явный лайфтайм:

impl<'a> Encryptor for Crypt<'a> {
    fn get_file(&self) -> Box<dyn File + 'a> {
        Box::new(F::new(self.wk, 11))
    }
}

Вопрос: каким образом, не меняя трейт, решить проблему с определением подходящего лайфтайма в имплементации?

Comments

[Василий Банников]

Попробуй тут спросить: https://t.me/rustlang_ru

[Владимир]

У самого опыта работы с растом не так много, но насколько я понимаю, ситуация получается следующая:
1. Метод fn get_file(&self) возвращает Box
2. Так как у возвращаемого типа Box нет явного ограничения лайфтайма, то согласно RFC 599, ему присваивается лайфтайм 'static
3. Но при этом тип File ограничен лайфтаймом 'a, отсюда и конфликт.

Не уверен, что с текущей архитектурой (указатель на объект в куче, который в свою очередь ссылается на объект в стеке) получится исправить не трогая трейт. Если есть возможность, то лично бы я либо постарался переписать так, что бы объекты внутри себя не содержали ссылок на поля других объектов, либо воспользовался Rc (подсчёт ссылок), либо вручную расставил необходимые ограничения лайфтаймов, как вы в итоге и сделали.

Можете еще попробовать спросить в официальном дискорде https://discord.gg/rust-lang

UPDATE
Как я решал бы эту задачу. Объект, который должен шериться между другими объектами (в моём случае это WrappedKey) заворачиваем сначала в Box, что бы переместить его из стека в кучу, а затем в Rc, что бы объект не умирал пока на него есть хоть одна ссылка.
Когда надо создать копию ссылки на объект (что бы пошарить этот объект), просто вызываете clone() у Rc.

Если объект надо шарить между разными потоками, то вместо Rc используйте Arc (Atomic RC).

[tmshit]

Asapin, спасибо!
Но если допустить, что трейт Encryptor находится совершенно в другом crate, и я не могу изменить его объявление под свои желания (от есть метод 100% должен вернуть Box<dyn AnotherTrait>), как быть в таком случае? Как вы и написали, только через избавление от ссылок или через Rc?

[Владимир]

tmshit, Как я решал бы эту задачу. Объект, который должен шериться между другими объектами (в моём случае это WrappedKey) заворачиваем сначала в Box, что бы переместить его из стека в кучу, а затем в Rc, что бы объект не умирал пока на него есть хоть одна ссылка.
Когда надо создать копию ссылки на объект (что бы пошарить этот объект), просто вызываете clone() у Rc.

Если объект надо шарить между разными потоками, то вместо Rc используйте Arc (Atomic RC).

[tmshit]

Asapin, Хм, интересно. Еще не приходилось работать с RC на практике, поэтому ваше решение выглядит интересным и познавательным для меня. Большое спасибо! Буду разбираться дальше :)

[tmshit]

Asapin, Добавьте ваш комментарий ответом, почему как решение

Answer 1

[Владимир]

У самого опыта работы с растом не так много, но насколько я понимаю, ситуация получается следующая:
1. Метод fn get_file(&self) возвращает Box
2. Так как у возвращаемого типа Box нет явного ограничения лайфтайма, то согласно RFC 599, ему присваивается лайфтайм 'static
3. Но при этом имплементация трейта File для структуры F ограничена лайфтаймом 'a, отсюда и конфликт.

Возможное решение:
Объект, который должен шериться между другими объектами (в моём примере это WrappedKey) заворачиваем сначала в Box, что бы переместить его из стека в кучу, а затем в Rc, что бы объект не умирал пока на него есть хоть одна ссылка.
Когда надо создать копию ссылки на объект (что бы пошарить этот объект), просто вызываете clone() у Rc.

Если объект надо шарить между разными потоками, то вместо Rcиспользуйте Arc(Atomic RC).