Odpowiedź.

Historia pytania:

W Rust system modułów ściśle kontroluje hierarchię i zależności między plikami i modułami. Gdy projekt się rozrasta, często pojawia się zadanie organizacji skomplikowanych zależności między częściami kodu (na przykład, jeśli typy z jednego modułu są potrzebne w innym). W innych językach (np. C/C++) taka sytuacja może prowadzić do cyklicznych zależności, niejawnych konfliktów i błędów w czasie kompilacji.

Problem:

W Rust nie można tworzyć bezpośrednich cyklicznych zależności (każdy moduł może odnosić się tylko w górę lub w dół hierarchii). Dlatego, jeśli na przykład typ A z modułu mod_a używa typu B z mod_b, a mod_b chce używać typu A, pojawia się sytuacja patowa. Nieprawidłowa organizacja może prowadzić do niemożności podziału projektu na niezależne komponenty lub do dublowania kodu.

Rozwiązanie:

Rust zaleca wprowadzanie wspólnych typów i traitów do oddzielnych modułów lub crates, a między nimi używanie zewnętrznych odniesień (fully qualified paths). Czasami pomocne jest przeniesienie interfejsów (trait) do oddzielnego pośredniego ogniwa. W ten sposób zależności stają się kierunkowe i łatwiej je analizować na etapie kompilacji.

Przykład kodu:

// src/common.rs
pub trait Drawable { fn draw(&self); }

// src/shapes/mod.rs
use crate::common::Drawable;
pub struct Circle { pub r: f64 }
impl Drawable for Circle { fn draw(&self) { /* ... */ } }

// src/scene.rs
use crate::common::Drawable;
pub struct Scene<T: Drawable> { pub items: Vec<T> }

Kluczowe cechy:

Wyodrębnienie wspólnego typu lub traita powyżej zależnych modułów
Przeniesienie zależnych typów do oddzielnego crate, jeśli to konieczne
Użycie fully qualified paths

Pytania z podstępem.

Czy można używać pub use, aby obejść cykliczne zależności i importować moduł z samego siebie?

Nie, pub use — nie jest rozwiązaniem dla cyklicznych zależności: działa tylko dla reekspozycji już zdefiniowanego elementu. Jeśli spróbujesz użyć pub use w przypadku modułu, który jeszcze nie został skompilowany lub zadeklarowany, wystąpi błąd kompilacji.

Dlaczego niedopuszczalne są forward declaration modułów, jak w C/C++?

W Rust nie ma mechanizmu wcześniejszego deklarowania typów lub modułów: wszystkie moduły, typy i stałe muszą być zadeklarowane i zdefiniowane na etapie kompilacji. Umożliwia to kompilatorowi pełne sprawdzenie hierarchii typów i unikanie nieoczekiwanych konfliktów. Forward declaration osłabiłoby gwarancje integralności systemu typów.

Czy można zrealizować wzajemne odwołania między strukturami dwóch modułów przez Box lub Rc?

Tak, jeśli typy są zgodne pod względem zależności (na przykład przez trait lub wspólny enum), można używać pośrednich odniesień (Box, Rc, Arc) między strukturami. Jednak to nie eliminuje wymogu deklaracji ich w zakresach widoczności, które nie tworzą rzeczywiście cyklicznych modułów.

Typowe błędy i antywzorce

Wielokrotne dublowanie trait lub type w różnych modułach
Próby odniesienia się do modułu nadrzędnego z podrzędnego bezpośrednio
Nadmierne użycie pub use bez omówienia architektury
Tworzenie pomocniczych dużych modułów, które mieszają wszystko w jedno

Przykład z życia

Negatywna sprawa

W projekcie stworzono oddzielne moduły shapes/mod.rs i render/mod.rs, ale oba zaczynają używać typów nawzajem bezpośrednio. Powstaje cykl zależności, kompilator zgłasza błąd unresolved import.

Zalety:

Dekompresja wg bloków tematycznych

Wady:

Niemozliwość skompilowania projektu
Słabo utrzymywana architektura

Pozytywna sprawa

Wspólne typy przeniesiono do modułu common, trait też przeniesiono, a zależności stały się jednostronne (scene zależy od shapes, shapes i scene — od common).