Go의 유형 시스템은 모든 구체적인 유형이 유한하고 정적으로 결정 가능한 메서드 세트를 가져야 한다고 규정합니다. 이는 O(1) 인터페이스 디스패치를 가능하게 합니다. 비제네릭 수신자의 메서드가 자신의 유형 매개변수를 선언할 수 있다면—예: func (t *MyType) Process[T any](x T)—그 유형은 이론적으로 무한한 메서드 세트를 가지게 되며, 이는 가능한 모든 유형 인수 T에 대해 지연 생성됩니다.
이 디자인은 메서드 포인터의 고정 오프셋에 의존하는 itab(인터페이스 테이블) 레이아웃 보장을 파괴합니다. 유형 매개변수를 유형 정의 자체에 제한함으로써 (예: type MyType[T any] struct{}), Go는 각 구체적인 인스턴스가 컴파일 시점에 완전하고 유한한 메타데이터 테이블을 생성하도록 보장합니다. 이는 이진 크기의 예측 가능성을 유지하고 정적 디스패치를 통해 인터페이스 호출의 성능 특성을 보존합니다.
고속 텔레메트리 파이프라인을 설계하는 동안, 우리 팀은 카운터, 히스토그램 및 게이지와 같은 이질적 데이터 유형을 수집할 수 있는 중앙 집중식 MetricCollector가 필요했습니다. 우리는 처음에 collector.Record[T Metric](value T)와 유사한 API를 원했으며, 여기서 MetricCollector는 사용자가 수집기를 매개변수화하지 않도록 하기 위해 구체적인 유형으로 남아야 했습니다.
문제가 즉시 발생했습니다: Go는 메서드 수준의 유형 매개변수를 거부했으며, 우리는 유형 소거(any를 저장하고 캐스팅)와 여러 제네릭 인스턴스로 수집기를 분할하는 것 중에서 선택해야 했습니다. 우리는 세 가지 뚜렷한 접근 방식을 평가했습니다.
첫째, 우리는 MetricCollector를 제네릭 유형 MetricCollector[T Metric]로 상승시키는 것을 고려했습니다. 이는 func (mc *MetricCollector[T]) Record(value T) 메서드를 허용합니다. 장점: 완전한 유형 안전성과 제로 할당 저장소. 단점: 카운터와 게이지에 대해 별도의 수집기 인스턴스가 필요하므로 혼합 메트릭을 단일 레지스트리에서 집계할 수 없습니다.
둘째, 우리는 각 메트릭 유형에 대해 RecordCounter, RecordGauge 등의 단일형 메서드를 만들기 위해 go:generate를 사용하는 코드 생성을 탐색했습니다. 장점: 유형 안전한 메서드를 가진 단일 수집기 인스턴스. 단점: 빌드 시간 복잡성, 불필요하게 부풀어진 소스 제어 및 새로운 메트릭 유형이 나타날 때마다 코드를 재생성해야 하는 필요성.
셋째, 우리는 패키지 수준의 제네릭 함수 func Record[T Metric](c *MetricCollector, value T)로 전환했습니다. 이 접근 방식은 수신자와 유형 매개변수를 분리했습니다. 장점: 단일 수집기 인스턴스를 유지하고, 함수의 컴파일러 단일형화에 의해 유형 안전성을 보존하며, 인터페이스 오버헤드를 회피했습니다. 단점: 사용자에게 수집기를 명시적 인수로 전달해야 하므로 약간 덜 관습적인 "객체 지향" 문법이 필요합니다.
우리는 API 인체공학과 Go의 건축적 제약을 균형 있게 조화시킨 세 번째 솔루션을 선택했습니다. 결과적으로 통합 인터페이스를 통해 이질적인 메트릭 유형을 처리할 수 있는 수집기가 생성되었으며, 모든 유형 불일치는 생산 배포 중이 아니라 컴파일 시점에 포착되었습니다.
type Metric interface { Type() string } type MetricCollector struct { storage map[string][]any } // 잘못된: func (mc *MetricCollector) Record[T Metric](value T) // 유효한: 명시적 수집기 인수를 가진 제네릭 함수 func Record[T Metric](mc *MetricCollector, value T) { key := value.Type() mc.storage[key] = append(mc.storage[key], value) }
왜 Go는 func (t *Tree[T]) Insert(x T)와 같은 메서드는 허용하지만 func (t *Tree) Insert[T](x T)는 거부합니까?
수신자 자체가 제네릭(Tree[T])일 때, 메서드 세트는 각 특정 유형 인수에 대해 구체적으로 인스턴스화됩니다 (예: Tree[int]는 Insert(x int) 메서드를 가집니다). 메서드 세트는 프로그램에 존재하는 유한한 인스턴스 집합에 연결되어 있기 때문에 유한하게 유지됩니다. 비제네릭 수신자인 경우, Insert[T]를 허용하면 무한한 유형 우주에 인덱스된 메서드의 무한 집합을 의미하며, 이는 Go의 정적 연결 및 빠른 인터페이스 호출 보장을 위반하는 런타임 메서드 사전 또는 동적 디스패치 테이블이 필요합니다.
구체적인 유형이 제네릭 메서드를 지원하면 인터페이스 충족이 어떻게 깨질까요?
Go에서 인터페이스 충족은 정적 검사에 의존합니다: 컴파일러는 유형이 메서드 시그니처를 비교하여 인터페이스를 구현하는지 확인합니다. 만약 MyType이 Method[T]()를 구현할 수 있다면, interface { Method[int]() }를 충족하는 것은 interface { Method[string]() }와 다를 것입니다. 컴파일러는 무한한 vtable 변형을 생성하거나 충족 검사 시점을 런타임으로 연기해야 하며, 이는 인터페이스 호출을 단순한 포인터 오프셋 조회에서 비싼 동적 해상도로 변환하여 언어의 성능 모델을 근본적으로 변경하게 됩니다.
구체적인 유형에서 구조체 필드를 사용하여 유형 매개변수를 시뮬레이션할 수 있습니까?
예, 하지만 중요한 의미의 거래가 있습니다. type Processor struct { handle func[T any](T) }와 같이 정의할 수 있지만, 이는 매개변수화된 메서드가 아닌 함수의 구체적 인스턴스를 저장하는 것입니다. 또는 reflect.Type에서 처리기 함수로의 맵을 저장할 수 있습니다. 장점: 런타임 유연성. 단점: 컴파일 타임 유형 안전성을 잃고, 반사 오버헤드가 발생하며, 구조체가 더 이상 그 작업을 요구하는 인터페이스를 충족할 수 없으므로 인터페이스 추상화가 깨집니다.