Как тут правильно времена жизни расставить в подобном? struct A {

b: Option<B>
}

impl A {
fn new() -> A
fn set_b(b: B)
}

impl I for A {
…
}


struct B {
i: &mut I
}

impl B {
fn new(i: &mut I)
}


fn main() {
let a = A::new();
let b = B::new(&a);
a.set_b(b);
}

Составь пожалуйста пример на плейграунде, где всё кроме непосредственной части которая касается твоего вопроса корректно, а не псевдокод, ладно? :) Это не заработает потому что тут двойное мутирующее заимствование, и лайфтаймы никак с этим не помогут.

Блин, а как тогда 2 структуры соединить чтобы они друг друга меняли? По факту, у меня ещё C есть, а A — адаптер между B и C.

Я не уверен что понял вопрос, но 2 структуры, которые могут друг друга мутировать по ссылкам — звучит плохо, так делать не стоит

Ммммм… А как тогда?

Я не знаю как тогда, зависит от того чего ты хочешь достичь.

норм. только ты не сможешь использовать такие структуры)

Понял. Спасибо)

При достаточном желании можно и в ансейф слазать)

при взятии ссылки на такую структуру ты получишь уб

Безусловно. > так делать не стоит

"обычно" эта задача решается через Arc/Rc

Есть какие-нибудь подобные примеры пощупать?

если с Rc можно заюзать RefCell, то брать мьютекс для арка уже оверинжиниринг какой-то

т.к. ты хочешь очень плохого, я направлю тебя на хороший гайд. https://rust-unofficial.github.io/too-many-lists/index.html пожалуйста, не пиши ансейфов и прочих небезопасных вещей, пока не пощупаешь язык несколько месяцев

Спокойно, в unsafe я не собираюсь.

прежде чем лезть в Arc/... можешь расскажешь зачем тебе понадобилось чтобы там друг друга разные структуры мутировали? Алсо дежурно напоминают что &mut означает не "мутабельную ссылку" а "уникальную ссылку". Очевидно взаимоссылающихся ссылок уникальных быть не может, потому что &a это то же самое что &a.b.a, а по условиям задачи ссылка на &a может быть только одна

но это если у тебя пара элементов. если у тебя их множество, то надо будет модифицировать подход

А есть такое же, только для b-tree (или хотя бы binary)?

Ну я уже думаю на тем, что бы а в принципе об A/I не знал