Il sistema di tipi di Go richiede che ogni tipo concreto possieda un insieme di metodi finito e staticamente determinabile per abilitare lo dispatch dell'interfaccia in O(1). Se un metodo su un ricevitore non generico potesse dichiarare i propri parametri di tipo—come func (t *MyType) Process[T any](x T)—il tipo, in teoria, mostrerebbe un insieme di metodi infinito, istanziato pigramente per ogni possibile argomento di tipo T.
Questo design annullerebbe le garanzie di layout della itab (tabella delle interfacce), che si basano su offset fissi per i puntatori dei metodi. Limitando i parametri di tipo alla definizione del tipo stesso (ad es. type MyType[T any] struct{}), Go garantisce che ogni istanza distinta produca una tabella di metadati completa e finita al momento della compilazione. Questo preserva la prevedibilità della dimensione binaria e mantiene le caratteristiche prestazionali delle chiamate all'interfaccia attraverso lo dispatch statico.
Durante l'architettura di un pipeline di telemetria ad alta capacità, il nostro team aveva bisogno di un MetricCollector centralizzato che potesse ingerire diversi tipi di dati—contatori, istogrammi e gauge—mantenendo la sicurezza del tipo al momento della compilazione. Inizialmente desideravamo un API simile a collector.Record[T Metric](value T), dove MetricCollector rimanesse un tipo concreto per evitare di costringere gli utenti a parametrizzare il collector stesso.
Il problema è emerso immediatamente: Go ha rifiutato il parametro di tipo a livello di metodo, costringendoci a scegliere tra la cancellazione del tipo (memorizzando any e facendo il cast) o frammentando il collector in più istanze generiche. Abbiamo valutato tre approcci distinti.
Per prima cosa, abbiamo considerato di elevare MetricCollector a un tipo generico MetricCollector[T Metric]. Questo avrebbe permesso il metodo func (mc *MetricCollector[T]) Record(value T). Pro: Sicurezza del tipo completa e memorizzazione senza allocazione. Contro: Gli utenti avrebbero richiesto istanze di collector separate per contatori rispetto ai gauge, eliminando la possibilità di aggregare metriche miste in un'unica registrazione senza box dell'interfaccia.
In secondo luogo, abbiamo esplorato la generazione del codice utilizzando go:generate per creare metodi monomorfizzati come RecordCounter, RecordGauge, ecc., per ogni tipo di metrica. Pro: Un'unica istanza del collector con metodi sicuri per i tipi. Contro: Complessità al momento della compilazione, controllo del codice sorgente gonfiato e la necessità di rigenerare il codice ogni volta che apparivano nuovi tipi di metrica.
In terzo luogo, abbiamo pivotato verso una funzione generica a livello di pacchetto func Record[T Metric](c *MetricCollector, value T). Questo approccio ha disaccoppiato il parametro di tipo dal ricevitore. Pro: Ha mantenuto un'unica istanza del collector, preservato la sicurezza del tipo attraverso la monomorfizzazione del compilatore della funzione e evitato l'overhead dell'interfaccia. Contro: Sintassi "orientata agli oggetti" leggermente meno idiomatica, richiedendo agli utenti di passare il collector come argomento esplicito piuttosto che come ricevitore del metodo.
Abbiamo scelto la terza soluzione perché bilanciava l'ergonomia dell'API con i vincoli architetturali di Go. Il risultato è stato un collector in grado di gestire tipi di metriche eterogenei attraverso un'interfaccia unificata, con tutti i mismatch di tipo catturati al momento della compilazione piuttosto che durante i deployment in produzione.
type Metric interface { Type() string } type MetricCollector struct { storage map[string][]any } // Non valido: func (mc *MetricCollector) Record[T Metric](value T) // Valido: Funzione generica con argomento collector esplicito func Record[T Metric](mc *MetricCollector, value T) { key := value.Type() mc.storage[key] = append(mc.storage[key], value) }
Perché Go consente metodi come func (t *Tree[T]) Insert(x T) ma rifiuta func (t *Tree) Insert[T](x T)?
Quando il ricevitore stesso è generico (Tree[T]), l'insieme di metodi viene instanziato concretamente per ciascun argomento di tipo specifico (ad es. Tree[int] ha un metodo Insert(x int)). L'insieme dei metodi rimane finito perché è legato all'insieme finito di istanze presenti nel programma. Per un ricevitore non generico, consentire Insert[T] implicherebbe una famiglia di metodi aperta indicizzata da un universo di tipi infinito, richiedendo dizionari di metodi a runtime o tabelle di dispatch dinamico che violerebbero il collegamento statico di Go e le garanzie di chiamata all'interfaccia rapida.
Come si romperebbe la soddisfazione dell'interfaccia se i tipi concreti supportassero metodi generici?
La soddisfazione dell'interfaccia in Go si basa su un controllo statico: il compilatore verifica che un tipo implementi un'interfaccia confrontando le firme dei metodi. Se MyType potesse implementare Method[T](), allora soddisfare interface { Method[int]() } sarebbe distinto da interface { Method[string]() }. Il compilatore dovrebbe generare infinite variazioni di vtable o rinviare i controlli di soddisfazione al runtime, trasformando le chiamate delle interfacce da semplici ricerche di offset di puntatori in risoluzioni dinamiche costose, alterando fondamentalmente il modello prestazionale del linguaggio.
Possono i parametri di tipo essere simulati su tipi concreti utilizzando campi di struttura che contengono funzioni generiche?
Sì, ma con compromessi semantici critici. Si può definire type Processor struct { handle func[T any](T) }, ma questo memorizza un'istanza concreta di una funzione, non un metodo parametrizzato. In alternativa, si può memorizzare una mappa di reflect.Type a funzioni handler. Pro: Flessibilità a runtime. Contro: Perde la sicurezza del tipo al momento della compilazione, comporta costi di riflessione e rompe l'astrazione dell'interfaccia perché la struttura non possiede più il metodo nel suo insieme di metodi—solo un campo—impedendo al tipo di soddisfare le interfacce che richiedono tale operazione.