потому что start_ref борровит start
Если что, Box::pin, но проблему не решит эт
Предположим раст пропустит это. Тогда если после этого кода дописать drop(dfa_states); dbg!(start_ref); То что произойдет?
Ну я бы ждал ошибку компиляции в духе "ты тут дропаешь с живой ссылкой на объект, окстись"
ну так он тебе это и говорит. Только он в момент дропа это уже отследить не может.
ты тут дропаешь муваешь с живой ссылкой на объект, акстись
У меня не абстрактная обёртка в вакууме, а Pin<Box<>>. Можно не делать вид, будто он ведёт себя случайным образом в зависимости от погоды и настроения?
я не думаю что в борровчекере какие-то специальные правила насчет пина или бокса
Он не настолько особенный
Я не вижу, что я делаю проблемного И не понимаю, что не нравится компилятору И как ему объяснить... что-нибудь
полагаю ты хочешь вот такое #![feature(hash_raw_entry)] use std::collections::HashMap; #[derive(Debug)] struct Foo; #[derive(PartialEq, Eq, Hash, Debug)] struct MyKey; fn main() { let mut map = HashMap::new(); let key = MyKey {}; let value = Foo {}; let (k, v) = map.raw_entry_mut().from_key(&key).or_insert_with(|| (key, value)); dbg!(k); dbg!(v); }
я тебе объяснил проблему - компилятор боится что у тебя останется ссылка на мертую память
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=82601422637413330ac9333b3444ae61
use std::collections::HashMap; #[derive(Debug)] struct Foo(i32); #[derive(PartialEq, Eq, Hash, Debug)] struct MyKey(i32); fn main() { let mut map = HashMap::new(); let key = MyKey(25); let value = Foo(77); let v = map.entry(key).insert_entry(value); let (k, v) = (v.key(), v.get()); dbg!(k); dbg!(v); }
Обсуждают сегодня