Storia. All'inizio, Rust richiedeva che tutti i tipi avessero una dimensione nota staticamente per garantire l'allocazione sulla stack e una semantica di valore efficiente. Quando furono introdotti i tipi di dimensione dinamica (DST) come gli slice [T] e gli oggetti di trait dyn Trait per supportare strutture dati flessibili, il linguaggio aveva bisogno di un meccanismo per distinguere tra parametri generici di dimensione fissa e potenzialmente non dimensionati, senza rompere il codice esistente. La sintassi ?Sized è stata adottata come un vincolo "rilassato", permettendo ai generici di escludere esplicitamente il requisito di dimensione predefinita Sized, mantenendo comunque il predefinito ergonomico per la maggior parte dei casi d'uso che non coinvolgono dati non dimensionati.
Il Problema. Il vincolo implicito T: **Sized** crea una tensione fondamentale: consente la manipolazione dei valori e i calcoli di memoria a tempo di compilazione, ma impedisce alle funzioni di accettare direttamente dyn Trait o tipi di slice senza indirection. Questa restrizione costringe gli sviluppatori a utilizzare Box o riferimenti anche quando si desiderano semantiche di possesso, complicando le API che mirano a supportare sia il polimorfismo statico che dinamico. Senza ?Sized, il codice generico non può astrarre su sia tipi concreti che oggetti polimorfici a tempo di esecuzione, portando a una forzata allocazione nello heap o interfacce duplicate per varianti di dimensione fissa e non dimensionata.
La Soluzione. Il compilatore risolve questo imponendo che i tipi vincolati da ?Sized possano essere accessibili solo tramite puntatori grassi—valori compositi contenenti un puntatore ai dati e metadati di runtime (lunghezza per gli slice, vtable per gli oggetti di trait). Quando un generico specifica T: **?Sized**, il compilatore impedisce operazioni che richiedono dimensioni note, come std::mem::size_of::<T>() o il trasferimento di valori per valore, garantendo che tutte le disposizioni di memoria rimangano calcolabili a tempo di compilazione. Questo design consente astrazioni senza costi aggiuntivi dove i tipi dimensionati utilizzano puntatori sottili e i tipi non dimensionati utilizzano puntatori grassi, con il sistema di tipi che gestisce in modo trasparente la distinzione.
Una libreria di monitoraggio dei sistemi aveva bisogno di registrare errori che potevano essere sia codici errore piccoli allocati nello stack che errori grandi, formattati dinamicamente implementando dyn **Display**. Il design iniziale dell'API utilizzando fn log<T: **Display**>(error: T) rifiutava gli oggetti di trait perché il vincolo implicito di Sized impediva a dyn Display di soddisfare il vincolo, creando un notevole ostacolo ergonomico per la gestione degli errori dinamici.
Il primo approccio considerato è stato quello di imporre Box<dyn **Display**> per tutti i tipi di errore, convertendo anche i semplici codici errore u32 in allocazioni nello heap. Pro: Unificava la superficie API e consentiva il possesso di errori dinamici senza complessi generici. Contro: Introduceva dipendenze dall'allocatore non adatte per target embedded e aggiungeva latenza misurabile ai percorsi caldi che gestivano errori semplici e statici.
La seconda opzione comportava il mantenimento di due metodi di registrazione separati: uno per tipi dimensionati generici T: **Display** e uno specificamente per &dyn **Display**. Pro: Evitava l'allocazione nello heap per tipi dimensionati e correttamente supportava il dispatch dinamico per errori complessi. Contro: Richiedeva una significativa duplicazione del codice, complicava la documentazione pubblica dell'API e costringeva i chiamanti a scegliere il metodo corretto basato sulla conoscenza anticipata della dimensione del tipo.
Il team ha selezionato un terzo approccio utilizzando fn log<T: **?Sized** + **Display**>(error: &T), accettando riferimenti a tipi sia dimensionati che non dimensionati. Questa soluzione è stata scelta perché mantenuta un'unica, coerente entry point API, supportava gli ambienti no-std evitando il mandatory boxing e imponeva un sovraccarico di runtime nullo rispetto all'approccio a due metodi. L'implementazione generica si compilava in codice macchina identico per tipi dimensionati rispetto alla versione monomorfica originale, mentre gestiva correttamente gli oggetti di trait attraverso il dispatch vtable.
Il crate risultante è stato distribuito con successo su microcontrollori e server, elaborando milioni di eventi di errore eterogenei senza sovraccarico di allocazione. L'interfaccia unificata ha consentito agli sviluppatori di passare sia &ConcreteError che &dyn Error senza soluzione di continuità, dimostrando che ?Sized consente un vero polimorfismo senza costi attraverso diversi obiettivi di distribuzione.
Perché una funzione non può restituire un valore di tipo T dove T: **?Sized**?
Le funzioni che restituiscono valori devono posizionare quei valori nei registri o nello stack, richiedendo una dimensione nota a tempo di compilazione per generare il codice corretto della convenzione di chiamata e riservare lo spazio appropriato dello stack. Poiché i tipi ?Sized come [i32] o dyn **Debug** hanno dimensioni determinate a runtime, il compilatore non può generare le sequenze di istruzioni di ritorno a dimensione fissa necessarie per l'ABI. Solo i tipi puntatore (Box<T>, &T) hanno dimensioni note staticamente (larghezza usize o puntatore grasso), rendendoli i soli tipi di ritorno legali per dati non dimensionati, restringendo fondamentalmente i generici ?Sized a tipi "view" piuttosto che a tipi "value" che possono essere spostati per valore.
Come interagisce **?Sized** con le regole di coerenza riguardanti le implementazioni di trait per i riferimenti?
Quando si implementano trait per &T dove T: **?Sized**, l'implementazione si applica automaticamente ai puntatori grassi (come &[i32] o &dyn Trait) poiché questi sono semplici riferimenti a tipi ?Sized. I candidati spesso trascurano che impl Trait per &T dove T: **?Sized** copre sia puntatori sottili che grassi, mentre impl Trait per T dove T: **Sized** non lo fa. Questa distinzione è cruciale per definire implementazioni generiche che funzionano con dati dimensionati e oggetti di trait, garantendo coerenza attraverso la gerarchia dei tipi senza implementazioni sovrapposte che violerebbero le regole degli orfani di Rust.
Cosa distingue la rappresentazione in memoria di **Box<dyn Trait>** da **&dyn Trait** oltre alle semantiche di possesso?
Sebbene entrambi utilizzino puntatori grassi (puntatore + vtable), **Box<dyn Trait>** possiede l'allocazione e memorizza il puntatore vtable specificamente per scopi di deallocazione, mentre **&dyn Trait** semplicemente osserva i dati. Crucialmente, Box<T> dove T: **?Sized** richiede che l'allocatore gestisca la deallocazione di dimensioni dinamiche utilizzando la dimensione memorizzata nel vtable, mentre i riferimenti non portano tale responsabilità. I principianti spesso trascurano che Box consente l'allocazione nello heap di tipi non dimensionati che non possono esistere nello stack, mentre i riferimenti semplicemente prendono in prestito la memoria esistente, rendendo Box essenziale per restituire dati non dimensionati posseduti dalle funzioni.