Historia: Przed ustabilizowaniem PhantomData w Rust 1.0, deweloperzy mieli trudności z wyrażeniem relacji typów dla struktur, które konceptualnie posiadały generyczne dane, ale przechowywały tylko surowe wskaźniki, na przykład podczas owijania uchwytów bibliotek C. Kompilator polegał wyłącznie na konkretnych polach, aby wnioskować o wariancji i własności, co prowadziło do zbyt restrykcyjnych błędów związanych z cyklami życia lub cichych naruszeń bezpieczeństwa pamięci, gdy borrow checker zakładał, że typ nie ma związku z jego zawartością. PhantomData wprowadzono jako zero-wymiarowy znacznik, aby explicytnie komunikować wariancję, własność i implikacje cech bez kosztów czasowych.
Problem: Rozważ niestandardowy wskaźnik inteligentny struct RawBox<T> { ptr: *const T }. Podczas gdy *const T jest kowariantny względem T, kompilator nie ma explicitnego potwierdzenia, że RawBox logicznie posiada wartość T, szczególnie w kontekście Drop Check (dropck). Bez PhantomData, kompilator traktuje T jako czysto syntetyczny parametr typowy, który struktura tylko wspomina, ale nie posiada, co potencjalnie pozwala na usunięcie T podczas gdy struktura nadal przechowuje surowy wskaźnik do jej pamięci. To zaniedbanie również uniemożliwia strukturze poprawne implementowanie automatycznych cech jak Send i Sync na podstawie właściwości T.
Rozwiązanie: Dodając pole PhantomData<T>, explicytnie oznaczasz RawBox jako kowariantny względem T i wskazujesz na logiczną własność. To zapewnia, że kompilator egzekwuje, że T przeżywa strukturę i stosuje odpowiednie zasady wariancji dla podtypów. W przypadkach wymagających różnej wariancji, PhantomData akceptuje różne konstruktory typów: PhantomData<fn(T)> tworzy kontrawariancję, podczas gdy PhantomData<*mut T> lub PhantomData<Cell<T>> wymuszają inwariancję. Ten mechanizm pozwala na bezpieczną abstrakcję nad surowymi wskaźnikami przy zachowaniu zerowych kosztów Rust.
Podczas opracowywania biblioteki do przetwarzania dźwięku o wysokiej wydajności, musiałem owinąć uchwyt API C *mut AudioContext, który był faktycznie typowany do struktury Rust AudioBuffer<T>, gdzie T mogło być f32 lub i16. Owijacz AudioHandle<T> przechowywał tylko surowy wskaźnik i wskaźnik vtable, ale musiałem, aby zachowywał się jak Box<AudioBuffer<T>> w kontekście cykli życia i bezpieczeństwa wątków. Konkretne, uchwyt musiał być Send, gdy T było Send, i kowariantny względem T, aby umożliwić bezproblemową substytucję typów próbek dźwięku.
Pierwsze podejście polegało na pominięciu wszelkich znaczników i poleganiu wyłącznie na polu *mut c_void. Ta strategia utrzymywała minimalny rozmiar struktury i unikała wszelkich powtarzalności, co były jej główne zalety. Jednak kompilator zakładał, że AudioHandle<T> jest inwariantne względem T i odmawiał implementacji Send, nawet gdy T było Send, ponieważ nie mógł zweryfikować własności, co ostatecznie naruszyło kontrakt API, który wymagał ruchu uchwytów między wątkami.
Drugie podejście rozważyło przechowywanie Option<Box<T> wyłącznie w celu wskazania systemowi typów. Ta metoda poprawnie ustaliła wariancję i pochodzenie Send/Sync, rozwiązując problemy z implementacją cech. Niestety, podwajała rozmiar struktury i wprowadzała złożoną logikę usuwania, która ryzykowała panikę, jeśli fałszywe pole nie było odpowiednio zsynchronizowane z wskaźnikiem C, co podważało cel abstrakcji za zerowy koszt.
Wybraną rozwiązaniem było dodanie marker: PhantomData<AudioBuffer<T>> do struktury. Ten zero-wymiarowy znacznik natychmiast przyznał kowariantną semantykę względem T, pozwolił na poprawne wyprowadzenie automatycznych cech na podstawie T i zapewnił, że Drop Check weryfikuje, że AudioBuffer<T> nie został usunięty przed uchwytem. W konsekwencji, wrapper FFI skompilował się bez błędów, nie narzucił żadnych kosztów czasowych i umożliwił bezpieczny ruch uchwytów audio między wątkami, gdy T było Send, doskonale spełniając wymagania biblioteki.
Dlaczego PhantomData<T> szczególnie wywołuje regułę Drop Check (dropck), która zapobiega usunięciu wartości, gdy dane referencyjne są nadal żywe, i co się stanie, gdyby tego nie było?
Bez PhantomData<T>, kompilator zakłada, że struktura nie posiada T, co pozwala na usunięcie T przez kod użytkownika, podczas gdy implementacja Drop struktury nadal trzyma surowy wskaźnik do pamięci T. To prowadzi do użycia po zwolnieniu pamięci, gdy destruktor się uruchamia, ponieważ pamięć mogła zostać ponownie przydzielona lub zatruwana. PhantomData sygnalizuje do dropck, że struktura koncepcyjnie zawiera T, zmuszając kompilator do weryfikacji, że T zdecydowanie przeżywa strukturę i zapobiegając temu braku bezpieczeństwa, mimo że T nie zajmuje żadnych bajtów w układzie.
Jak można wykorzystać PhantomData, aby wymusić kontrawariancję względem parametru typowego i w jakim rodzaju projektowania API jest to niezbędne?
Kontrawariancję osiąga się poprzez użycie PhantomData<fn(T)>. To jest niezbędne dla typów przechowujących zwrotnych, jak struct Comparator<T> { compare: fn(T, T) -> Ordering, _marker: PhantomData<fn(T)> }. Ponieważ fn(T) jest kontrawariantne względem T, struktura poprawnie modeluje, że komparator akceptujący &'static str może być używany wszędzie tam, gdzie oczekiwany jest komparator &'short str, co jest przeciwną relacją do kowariancji i kluczowym aspektem podtypowania wskaźników funkcyjnych.
Co odróżnia implikacje wariancji PhantomData<Cell<T>> od PhantomData<T>, i dlaczego struktura opakowująca nieskalowalny pierwotny mutowalny byt wymagałaby tej pierwszej?
PhantomData<T> implikuje kowariancję, podczas gdy PhantomData<Cell<T>> implikuje inwariancję, ponieważ Cell jest inwariantny względem swojej zawartości. Podczas budowania niestandardowego kontenera opartego na UnsafeCell jak MyRefCell<T>, inwariancja jest obowiązkowa, aby zapobiec przekształceniu MyRefCell<&'long str> do MyRefCell<&'short str>. Taka konwersja umożliwiłaby przechowywanie referencji o krótkim czasie życia tam, gdzie oczekiwana była długowieczna, naruszając zasady aliasowania i powodując wiszące wskaźniki przy operacjach zapisu, co inwariantny znacznik zapobiega.