Go言語入門：よくある質問 -Type Parameters Vol.7-

本日は、Go言語のよくある質問 について解説しています。

背景

Go言語を学んでいると「なんでこんな仕様になっているんだろう？」「他の言語と違うのはなぜ？」といった疑問が湧いてきませんか。Go言語の公式サイトにあるFAQページには、そんな疑問に対する開発チームからの丁寧な回答がたくさん載っているんです。ただ、英語で書かれているため読むのに少しハードルがあるのも事実で、今回はこのFAQを日本語に翻訳して、Go言語への理解を深めていけたらと思い、これを読んだ時の内容を備忘として残しました。

Type Parameters

なぜコンパイラは私のプログラムの型引数を推論できないのか?

プログラマーがジェネリック型や関数の型引数が何であるべきか簡単に分かる多くのケースがありますが、言語はコンパイラにそれを推論することを許可していません。型推論は、どの型が推論されるかについて決して混乱が生じないことを保証するために、意図的に制限されています。他の言語での経験から、予期しない型推論はプログラムを読んだりデバッグしたりする際にかなりの混乱を招く可能性があることが示唆されています。呼び出しで使用する明示的な型引数を指定することは常に可能です。将来的には、ルールがシンプルで明確なままである限り、新しい形式の推論がサポートされる可能性があります。

解説

この問題は何について説明しているの?

Goのジェネリクスでは、型推論(コンパイラが自動的に型を判断すること)が意図的に制限されています。「明らかに分かるのに、なぜコンパイラは推論してくれないの?」という疑問に答える内容です。

基本的な用語

• 型推論: コンパイラが文脈から型を自動的に判断する機能
• 型引数: ジェネリクスに渡す具体的な型(例: List[int]のint部分)
• 明示的な型指定: プログラマーが型を明確に書くこと

具体例で見てみよう

例1: 推論が効く場合

func Print[T any](x T) {
    fmt.Println(x)
}

// 型引数を省略できる(推論される)
Print(42)        // T は int と推論される
Print("hello")   // T は string と推論される

これは問題なく動作します。引数から型が明らかだからです。

例2: 推論が効かない場合

func MakeSlice[T any](size int) []T {
    return make([]T, size)
}

// これはエラー! Tを推論できない
result := MakeSlice(10)

// 明示的に指定する必要がある
result := MakeSlice[int](10)  // OK

この場合、sizeはintですが、返り値のTは何の型か分かりません。

例3: 人間には明らかでもコンパイラは推論しない

func Convert[T any](x string) T {
    // 何らかの変換処理
}

var num int
num = Convert(("123")  // エラー! Tを推論できない

// 明示的に指定する
num = Convert[int]("123")  // OK

人間が見れば「numはintだから、Tはintでしょ?」と分かりますが、Goはこれを推論しません。

なぜ推論を制限しているの?

理由1: 混乱を防ぐため

他のプログラミング言語(C++のテンプレートなど)では、複雑な型推論により:

// 他の言語の例(疑似コード)
auto result = someFunction(x, y, z);
// resultの型は? 推論ルールが複雑で分かりにくい!

コードを読むときやデバッグするときに「この変数の型は何?」が分からなくなることがあります。

理由2: シンプルで明確なルール

Goの型推論ルールは非常にシンプルです:

「関数の引数から直接型が分かる場合のみ推論する」

これにより:

• コードを読む人が混乱しない
• コンパイラエラーが分かりやすい
• デバッグが簡単

理由3: 予測可能性

// 推論が複雑だと...
result := Process(data)  
// この型は? ケースバイケースで変わる?

// シンプルなら明確
result := Process[int](data)  
// 型が明確! 読みやすい!

推論されないときはどうすればいい?

解決策: 型引数を明示的に指定する

// 型を明示的に書く
result := MakeSlice[int](10)
value := Convert[string](data)
list := NewList[*User]()

最初は面倒に感じるかもしれませんが:

• メリット: コードが明確で読みやすい
• デメリット: 少し冗長

将来の可能性

文章によると、将来的には:

• ルールがシンプルで明確なまま
• 新しい推論のパターンが追加されるかも

しかし、「複雑で混乱を招く推論」は追加されません。

まとめ

• Goの型推論は意図的に制限されている
• 理由はシンプルさと明確さを保つため
• 他の言語では複雑な推論が混乱を招いた経験がある
• 推論されない場合は明示的に型を指定する
• これはバグではなく、設計上の判断

覚えておくべきルール

✅ 推論される: 関数の引数から型が明らか

Print(42)  // 引数が int なので T は int

❌ 推論されない: 返り値だけから型を判断する必要がある

MakeSlice(10)  // 何のスライス? 分からない!

Goの哲学は「明示的であることは、暗黙的であることより良い」です。少し冗長でも、コードの意図が明確な方が、長期的にはメンテナンスしやすいプログラムになります!

おわりに 

本日は、Go言語のよくある質問について解説しました。