Rust wymaga, aby wszystkie typy używane jako pola w strukturach lub elementy w tablicach implementowały trait Sized, co zapewnia kompilatorowi możliwość obliczania stałych przesunięć pamięci i układów ramek stosów w czasie kompilacji. Konstrukcja dyn Trait reprezentuje obiekt traitu z dynamicznie przekazywanymi metodami, który jest z natury !Sized (nie mający rozmiaru), ponieważ konkretny typ stojący za interfejsem jest zatarte, co pozwala na różnorodne implementacje o różnych rozmiarach pamięci zajmujących ten sam abstrakcyjny typ. Aby ułatwić dynamiczny dispatch, Rust reprezentuje dyn Trait jako gruby wskaźnik—struktura składająca się z dwóch słów zawierająca wskaźnik danych do obiektu oraz wskaźnik vtable trzymający adresy metod i informacje o destruktorach—jednak sam typ pozostaje nie mający rozmiaru, ponieważ rozmiar wskazywanego obiektu jest nieznany. W związku z tym umieszczanie dyn Trait bezpośrednio w linii naruszyłoby ograniczenie Sized, ponieważ kompilator nie może określić granic struktury ani kroku tablicy; wymagana jest indykacja przez Box, Rc, Arc lub referencje &, aby owinąć gruby wskaźnik w pojemniku Sized.
Projektujesz architekturę pluginów dla silnika gry, gdzie modderzy dostarczają różnorodne implementacje traitu Behavior—niektóre przechowują proste flagi całkowite, inne utrzymują duże siatki haszujące przestrzennie—i silnik musi utrzymywać kolekcję aktywnych zachowań w strukturze GameState.
Próba zdefiniowania struct GameState { behaviors: Vec<dyn Behavior> } natychmiast powoduje błąd kompilacji z informacją, że dyn Behavior nie ma stałego rozmiaru znanego w czasie kompilacji, uniemożliwiając budowę.
Jednym z rozważanych rozwiązań była wykorzystanie Vec<&dyn Behavior> do przechowywania pożyczonych obiektów traitu, unikając alokacji pamięci dla wskaźników samych w sobie. To podejście narzuca surowe ograniczenia żywotności, wymagając, aby wszystkie dane pluginu żyły co najmniej tak długo jak GameState i komplikuje scenariusze gorącego ponownego ładowania, w których pluginy są dynamicznie odładowywane, co ostatecznie okazuje się zbyt restrykcyjne dla silnika, który można modyfikować.
Inną ocenianą alternatywą było wykorzystanie dispatchingu enum, definiując enum BehaviorType { Ai(AiModule), Physics(PhysicsBody) } do opakowania wszystkich znanych implementacji. Choć to zapewnia statyczny dispatch i doskonałą lokalność w pamięci podręcznej, tworzy zamknięty zbiór wymagający modyfikacji rdzenia silnika dla każdego nowego pluginu, naruszając zasadę otwartości/zamkniętości i uniemożliwiając zewnętrzne rozszerzenia binarne bez ponownego kompilowania silnika.
Wybrane rozwiązanie wykorzystało Vec<Box<dyn Behavior>>, alokując pamięć na każdym wystąpieniu zachowania i przechowując wynikowe grube wskaźniki w wektorze. To zaspokoiło wymaganie Sized przez indykację Box, zachowując polimorfizm w czasie wykonania i pozwalając na heterogeniczne kolekcje, choć wprowadziło przewidywalne koszty fragmentacji pamięci stosu, które zostały złagodzone przez niestandardowy allocator areny dla małych komponentów zachowania.
Jak CoerceUnsized ułatwia konwersję z Box<T> na Box<dyn Trait> bez alokacji nowego vtable w czasie wykonania i jakie ograniczenia dotyczące układu pamięci to narzuca na wskazywany obiekt?
CoerceUnsized to znacznik przypadków wszystkich wskaźników, takich jak Box, Rc i Arc, który umożliwia coercje nieskalowane. Podczas konwersji Box<Concrete> na Box<dyn Trait>, kompilator generuje vtable dla Concrete, który zaimplementował Trait statycznie podczas kompilacji, wbudowując go w sekcji tylko do odczytu binarnej. Coercja jedynie reinterpretowuje metadane wskaźnika, poszerzając je z cienkiego wskaźnika (pojedyncze słowo) do grubego wskaźnika (adres danych + adres vtable) bez przenoszenia danych podłoża ani alokowania pamięci w czasie wykonania. To narzuca surowe ograniczenie, że konkretny typ musi posiadać kompatybilny układ pamięci z oczekiwaną reprezentacją obiektu traitu—konkretnie, wskaźnik danych musi być wyjustowany z początkiem obiektu, gdzie vtable oczekuje pól, a typ musi przestrzegać gwarancji reprezentacji #[repr(Rust)] lub kompatybilności, co zapewnia, że przesunięcia metod w vtable poprawnie odniesie się do funkcji konkretnej implementacji.
Dlaczego Rust zabrania tworzenia obiektów traitów (dyn Trait) z traitów, które definiują metody konsumpcyjne Self przez wartość (fn consume(self)), i jak to się odnosi do wymogu Sized dla typów zwracanych przez funkcje?
To zakaz wynika z zasad bezpieczeństwa obiektów. Kiedy metoda konsumuje self przez wartość, kompilator musi znać dokładny rozmiar typu konkretnego, aby wygenerować odpowiednią ramkę stosu do przesuwania wartości i aby wstawić prawidłowe wywołanie destruktora w odpowiednim przesunięciu pamięci. W kontekście dyn Trait, konkretny typ jest zatarte; podczas gdy vtable zawiera informacje o rozmiarze i o wywołaniu, ramka stosu wywołującego nie może być dynamicznie dostosowana, aby pomieścić nieznany rozmiar przesuwanej wartości. Co więcej, metody zwracające Self wymagałyby od wywołującego przydzielenia miejsca na zwracane sloty o nieznanym rozmiarze. Aby zapobiec uszkodzeniu stosu i nieokreślonym zachowaniom, Rust zabrania obiektów traitów dla traitów z metodami kind, które działają przez wartość self, co zapewnia, że wszystkie interakcje odbywają się przez indykację (&self lub &mut self), gdzie rozmiar wskaźnika jest stały.
Jaka jest różnica między tym, że dyn Trait automatycznie implementuje Send, gdy Trait ma Send jako supertrait, a tym, że wyraźnie annotujemy dyn Trait + Send, i dlaczego brak obu prowadzi do nieprzechodzenia obietnicy bezpieczeństwa wątkowego, mimo że konkretna instancja za wskaźnikiem implementuje Send?
Kiedy Trait deklaruje Send jako supertrait (np. trait Trait: Send {}), kompilator propaguje to ograniczenie, automatycznie implementując Send dla dyn Trait, ponieważ każdy implementator musi koniecznie być Send. Z drugiej strony, jeśli Trait nie ma tego supertraitu, zapisując dyn Trait + Send, wyraźnie tworzy obiekt traitu, który akceptuje tylko konkretne typy implementujące zarówno Trait, jak i Send, zawężając dopuszczalne typy w miejscu coerce. Jeśli ani supertrait, ani jawne ograniczenie nie istnieje, dyn Trait nie implementuje Send, nawet jeśli konkretna instancja za wskaźnikiem jest bezpieczna wątkowo, ponieważ zatarcie typów wyrzuca te informacje—kompilator nie może zagwarantować, że wszystkie możliwe typy, które mogą zajmować to miejsce vtable, są Send. To zapobiega przypadkowemu przesyłaniu typów, które nie są bezpieczne wątkowo, przez granice wątków poprzez zatarcie typu obiektu traitu.