Go ジェネリクスと型パラメータ

---

ジェネリクスをいつ使うか

まず具体的な型で書く。2 番目の型が現れたときだけジェネリクスを使う。

ジェネリクスを優先する場合

• 複数の型が同じロジックを共有している（ソート、フィルタリング、map/reduce）
• そうでなければ any と過度なタイプスイッチに依存することになる
• 再利用可能なデータ構造を構築している（並行安全なセット、順序付きマップ）

ジェネリクスを避ける場合

• 実際には 1 つの型しかインスタンス化されていない
• インターフェースが共有の動作をきれいにモデル化している
• ジェネリクスコードが型固有の代替案より読みにくい

「コードを書く、型を設計するのではない」— Robert Griesemer and Ian Lance Taylor

判断フロー

複数の型が同じロジックを共有していますか？
├─ いいえ  → 具体的な型を使う
├─ はい → 有用なインターフェースを共有していますか？
│        ├─ はい → インターフェースを使う
│        └─ いいえ  → ジェネリクスを使う

悪い例：

// 早すぎるジェネリクス化：実際には int でしか呼ばれない
func Sum[T constraints.Integer | constraints.Float](vals []T) T {
    var total T
    for _, v := range vals {
        total += v
    }
    return total
}

良い例：

func SumInts(vals []int) int {
    var total int
    for _, v := range vals {
        total += v
    }
    return total
}

---

型パラメータの命名

名前	典型的な用途
T	汎用型パラメータ
K	マップキー型
V	マップ値型
E	要素型

複雑な制約の場合は、短い説明的な名前も許容されます：

func Marshal[Opts encoding.MarshalOptions](v any, opts Opts) ([]byte, error)

---

型エイリアスと型定義

型エイリアス（type Old = new.Name）はめったに使わない — パッケージの移行や段階的な API リファクタリング時だけ使う。

---

制約の合成

~（基礎型）と |（ユニオン）で制約を組み合わせる：

type Numeric interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64 |
    ~float32 | ~float64
}

func Sum[T Numeric](vals []T) T {
    var total T
    for _, v := range vals {
        total += v
    }
    return total
}

独自の制約を書く代わりに、constraints パッケージまたは cmp パッケージ（Go 1.21+）の cmp.Ordered などの標準的な制約を使う。

カスタム型制約を書く、~ と | で制約を合成する、または型推論の問題をデバッグする場合は references/CONSTRAINTS.md を参照してください。

---

よくあるピットフォール

標準ライブラリの型をラップしない

// 悪い例：ジェネリックラッパーは値なしで複雑性を追加する
type Set[T comparable] struct {
    m map[T]struct{}
}

// 良い例：使用がシンプルな場合は map[T]struct{} を直接使う
seen := map[string]struct{}{}

ジェネリクスが複雑性に見合う価値があるのは、複数の呼び出しサイト間の重複を排除する場合です。単一用途のジェネリクスは単なる間接参照です。

インターフェース実装のためにジェネリクスを使わない

// 悪い例：T はインターフェース満たすためだけに使われる — インターフェースを直接使う
func Process[T io.Reader](r T) error { ... }

// 良い例：インターフェースを直接受け入れる
func Process(r io.Reader) error { ... }

過度に制約を厳しくしない

// 悪い例：制約は必要以上に制限的
func Contains[T interface{ ~int | ~string }](slice []T, target T) bool { ... }

// 良い例：comparable で十分
func Contains[T comparable](slice []T, target T) bool { ... }

---

クイックリファレンス

トピック	ガイダンス
ジェネリクスをいつ使うか	複数の型が同じロジックを共有し、インターフェースが不十分な場合のみ
開始地点	まず具体的なコードを書く；後で汎用化する
命名	単一の大文字（T、K、V、E）
型エイリアス	同じ型、別の名前；移行目的でのみ使う
制約の合成	基礎型には ~、ユニオンには `
よくあるピットフォール	単一用途コードをジェネリクス化しない；インターフェースで十分な場合も同様

---

関連スキル

• インターフェースとジェネリクス: インターフェースが既に共有の動作をジェネリクスなしでモデル化しているかを判断する場合は go-interfaces を参照
• 型の宣言: 新しい型を定義するとき、型エイリアスを選ぶとき、または型定義とエイリアスのどちらかを選ぶときは go-declarations を参照
• ジェネリック API のドキュメント化: ジェネリック関数の doc コメントと実行可能なサンプルを書く場合は go-documentation を参照
• 型パラメータの命名: 型パラメータまたは制約インターフェースの名前を選ぶ場合は go-naming を参照