System typów Go wymaga, aby każdy typ konkretny posiadał ograniczony, statycznie określany zestaw metod, aby umożliwić O(1) dispatch interfejsów. Gdyby metoda na nieogólnym odbiorniku mogła deklarować swoje własne parametry typu — na przykład func (t *MyType) Process[T any](x T) — teoretycznie typ ten wykazywałby nieskończony zestaw metod, instanciowany leniwie dla każdego możliwego argumentu typu T.
Ten projekt zniszczyłby gwarancje układów itab (tabeli interfejsów), które opierają się na stałych przesunięciach dla wskaźników metod. Ograniczając parametry typu do definicji typu (np. type MyType[T any] struct{}), Go zapewnia, że każda odrębna instancja produkuje kompletną, ograniczoną tabelę metadanych w czasie kompilacji. To zachowuje przewidywalność rozmiaru binarnego i utrzymuje charakterystyki wydajności wywołań interfejsów przez statyczne dispatchowanie.
Podczas projektowania pipeline'u telemetrycznego o wysokiej przepustowości, nasz zespół potrzebował scentralizowanego MetricCollector, który mógłby przetwarzać różnorodne typy danych — liczniki, histogramy i wskaźniki — przy jednoczesnym zachowaniu bezpieczeństwa typów w czasie kompilacji. Początkowo pożądaliśmy API przypominającego collector.Record[T Metric](value T), gdzie MetricCollector pozostałby typem konkretnym, aby uniknąć zmuszania użytkowników do parametryzacji samego kolektora.
Problem pojawił się od razu: Go odrzucił parametr typu na poziomie metody, zmuszając nas do wyboru pomiędzy usunięciem typów (przechowywaniem any i rzutowaniem) a fragmentacją kolektora na kilka ogólnych instancji. Oceniliśmy trzy różne podejścia.
Po pierwsze, rozważaliśmy podniesienie MetricCollector do ogólnego typu MetricCollector[T Metric]. To pozwoliłoby na metodę func (mc *MetricCollector[T]) Record(value T). Zalety: pełne bezpieczeństwo typów i brak alokacji pamięci. Wady: Użytkownicy potrzebowali oddzielnych instancji kolektorów dla liczników i wskaźników, eliminując możliwość agregacji mieszanych metryk w jednej rejestrze bez „opakowywania” interfejsów.
Po drugie, zbadaliśmy generowanie kodu z użyciem go:generate, aby stworzyć zmonomorfizowane metody, takie jak RecordCounter, RecordGauge itp., dla każdego typu metryki. Zalety: pojedyncza instancja kolektora z metodami bezpiecznymi typowo. Wady: złożoność w czasie budowy, nadmierna kontrola źródła i konieczność regeneracji kodu za każdym razem, gdy pojawiały się nowe typy metryk.
Po trzecie, przeszliśmy do ogólnej funkcji na poziomie pakietu func Record[T Metric](c *MetricCollector, value T). To podejście oddzieliło parametr typu od odbiornika. Zalety: zachowana pojedyncza instancja kolektora, zachowane bezpieczeństwo typów poprzez monomorfizację kompilatora funkcji oraz uniknięcie narzutu interfejsu. Wady: nieco mniej idiomatyczna składnia „obiektowa”, wymagająca, aby użytkownicy przekazywali kolektor jako expliczny argument zamiast odbiornika metody.
Wybraliśmy trzecie rozwiązanie, ponieważ równoważyło ergonomię API z architektonicznymi ograniczeniami Go. Rezultatem był kolektor zdolny do obsługi heterogenicznych typów metryk poprzez zjednoczony interfejs, z wszystkimi niezgodnościami typów wykrywanymi w czasie kompilacji, a nie podczas wdrożeń produkcyjnych.
type Metric interface { Type() string } type MetricCollector struct { storage map[string][]any } // Nieprawidłowe: func (mc *MetricCollector) Record[T Metric](value T) // Prawidłowe: ogólna funkcja z explicznym argumentem kolektora func Record[T Metric](mc *MetricCollector, value T) { key := value.Type() mc.storage[key] = append(mc.storage[key], value) }
Dlaczego Go zezwala na metody takie jak func (t *Tree[T]) Insert(x T), ale odrzuca func (t *Tree) Insert[T](x T)?
Gdy odbiornik sam jest ogólny (Tree[T]), zestaw metod jest instancjonowany konkretnie dla każdego specyficznego argumentu typu (np. Tree[int] ma metodę Insert(x int)). Zestaw metod pozostaje ograniczony, ponieważ jest związany z ograniczonym zestawem instancji obecnych w programie. Dla nieogólnego odbiornika, zezwolenie na Insert[T] sugerowałoby otwartą rodzinę metod indeksowanych przez nieskończony wszechświat typów, wymagając słowników metod w czasie wykonywania lub dynamicznych tabel dispatchingowych, które naruszają gwarancje statycznego łączenia i szybkiego wywoływania interfejsów w Go.
Jak naruszyłoby to spełnienie interfejsu, jeśli typy konkretne wspierałyby ogólne metody?
Spełnienie interfejsu w Go opiera się na statycznej kontroli: kompilator weryfikuje, że typ implementuje interfejs przez porównanie sygnatur metod. Jeśli MyType mógłby implementować Method[T](), wtedy spełnienie interface { Method[int]() } byłoby inne niż interface { Method[string]() }. Kompilator musiałby generować nieskończone wariacje vtable lub opóźnić kontrole spełnienia do czasu wykonania, co przekształcałoby wywołania interfejsów z prostych wyszukiwań przesunięcia wskaźnika w kosztowne dynamiczne rozwiązania, zasadniczo zmieniając model wydajności języka.
Czy parametry typów można zasymulować w typach konkretnych za pomocą pól struktury, które przechowują funkcje ogólne?
Tak, ale z krytycznymi kompromisami semantycznymi. Można zdefiniować type Processor struct { handle func[T any](T) }, ale to przechowuje konkretną instancję funkcji, a nie parametryzowaną metodę. Alternatywnie, można przechowywać mapę reflect.Type do funkcji obsługi. Zalety: elastyczność w czasie wykonywania. Wady: traci bezpieczeństwo typów w czasie kompilacji, wiąże się z dodatkowym narzuceniem refleksji i łamie abstrakcję interfejsu, ponieważ struktura nie posiada metody w swoim zestawie metod — tylko pole — uniemożliwiając typowi spełnianie interfejsów wymagających tej operacji.