> Source: https://www.ymotongpoo.com/works/goblog-ja/type-inference/
# 型推論について知りたかったすべてのこと、そしてもう少し
[Everything You Always Wanted to Know About Type Inference - And a Little Bit More](https://go.dev/blog/type-inference) by Robert Griesemer
本記事は、私がGopherCon 2023（サンディエゴ開催）で行った型推論についての講演をブログ向けに書き起こしたもので、内容を多少拡張し、わかりやすくなるよう手を加えています。
## 型推論とは何か
Wikipediaでは型推論を次のように定義しています。
> 型推論とは、コンパイル時に式の型を部分的に、あるいは完全に自動で導き出す機能のことです。多くの場合、コンパイラは明示的な型注釈が与えられていなくても、変数の型や関数の型シグネチャを推論できます。
ここで重要なのは「式の型を……自動で導き出す」という部分です。Goは当初から基本的な形の型推論をサポートしていました。
```go
const x = expr // xの型はexprの型
var x = expr
x := expr
```
これらの宣言では明示的な型が与えられていないため、`=` や `:=` の左辺にある定数や変数 `x` の型は、右辺に置かれたそれぞれの初期化式の型になります。これを、型は初期化式の型から「推論される」と言います。Go 1.18でジェネリクスが導入されたことで、Goの型推論の能力は大幅に拡張されました。
### なぜ型推論が必要か
ジェネリクスを使わない通常のGoのコードでは、型を省略する効果は短縮変数宣言においてもっとも顕著に現れます。この宣言は、型推論と、`var` キーワードを省略できるというちょっとした糖衣構文とを組み合わせて、非常にコンパクトな1文にまとめたものです。次のマップ変数の宣言を考えてみましょう。
```go
var m map[string]int = map[string]int{}
```
対して
```go
m := map[string]int{}
```
`:=` の左辺の型を省略することで、重複がなくなると同時に可読性も高まります。
ジェネリクスを使ったGoのコードでは、コード中に現れる型の数が大幅に増える可能性があります。型推論がなければ、ジェネリック関数やジェネリック型を具体化するたびに型引数が必要になります。そのため、型引数を省略できることはより一層重要になります。新しい[slicesパッケージ](https://pkg.go.dev/slices)にある次の2つの関数を使う場合を考えてみましょう。
```go
package slices
func BinarySearch[S ~[]E, E cmp.Ordered](x S, target E) (int, bool)
func Sort[S ~[]E, E cmp.Ordered](x S)
```
型推論がなければ、`BinarySearch` や `Sort` を呼び出す際には明示的な型引数が必要です。
```go
type List []int
var list List
slices.Sort[List, int](list)
index, found := slices.BinarySearch[List, int](list, 42)
```
このようなジェネリック関数の呼び出しのたびに `[List, int]` を繰り返し書きたくはありません。型推論を使えば、コードは次のように単純化されます。
```go
type List []int
var list List
slices.Sort(list)
index, found := slices.BinarySearch(list, 42)
```
こちらのほうがすっきりしていてコンパクトです。実際、これはジェネリクスを使っていないコードとまったく同じに見えますが、それを可能にしているのが型推論です。
重要なのは、型推論はあくまで任意の仕組みだということです。型引数を書いたほうがコードが明確になるのであれば、遠慮なく書いてかまいません。
## 型推論は型パターンマッチングの一種
型推論は、型パターン同士を比較します。ここでの型パターンとは、型パラメータを含む型のことです。この後すぐに明らかになる理由から、型パラメータは_型変数_と呼ばれることもあります。型パターンのマッチングによって、これらの型変数に入れるべき型を推論できます。簡単な例を見てみましょう。
```go
// slicesパッケージより
// func Sort[S ~[]E, E cmp.Ordered](x S)
type List []int
var list List
slices.Sort(list)
```
`Sort` 関数の呼び出しでは、変数 `list` が [`slices.Sort`](https://pkg.go.dev/slices#Sort) のパラメータ `x` に対する関数引数として渡されます。したがって、`list` の型である `List` は、`x` の型である型パラメータ `S` と一致しなければなりません。`S` が `List` という型を持てば、この代入は有効になります。実際には[代入のルール](https://go.dev/ref/spec#Assignability)は複雑ですが、ここではひとまず両者の型が同一でなければならないと考えておけば十分です。
`S` の型を推論できたので、次は `S` の[型制約](https://go.dev/ref/spec#Type_constraints)に目を向けられます。チルダ `~` 記号があることから、`S` の[基底型](https://go.dev/ref/spec#Underlying_types)は `[]E` というスライスでなければならないとわかります。`S` の基底型は `[]int` なので、`[]int` は `[]E` と一致しなければならず、そこから `E` は `int` でなければならないと結論づけられます。こうして、対応する型同士が一致するように `S` と `E` の型を見つけられました。推論は成功です!
次はもっと複雑な例で、多くの型パラメータが登場します。`slices.EqualFunc` からの `S1`、`S2`、`E1`、`E2`、そしてジェネリック関数 `equal` からの `E1` と `E2` です。ローカル関数 `foo` は `equal` 関数を引数として `slices.EqualFunc` を呼び出します。
```go
// slicesパッケージより
// func EqualFunc[S1 ~[]E1, S2 ~[]E2, E1, E2 any](s1 S1, s2 S2, eq func(E1, E2) bool) bool
// ローカルのコード
func equal[E1, E2 comparable](E1, E2) bool { … }
func foo(list1 []int, list2 []float64) {
…
if slices.EqualFunc(list1, list2, equal) {
…
}
…
}
```
これは、型パラメータの数だけ、つまり最大6個の型引数を省略できるという、型推論がまさに真価を発揮する例です。型パターンのマッチングという考え方自体はここでも通用しますが、型同士の関係が増えていくにつれてすぐに複雑になっていくことがわかります。どの型パラメータとどの型が、どのパターンに関わっているのかを見極めるための体系的な手法が必要です。
型推論を少し違う角度から眺めてみると、理解の助けになります。
## 型方程式
型推論は、型方程式を解く問題として捉え直せます。方程式を解くというのは、誰もが高校の数学で慣れ親しんできたはずです。幸い、型方程式を解く問題は、これから見ていくようにもっと単純なものです。
先ほどの例をもう一度見てみましょう。
```go
// slicesパッケージより
// func Sort[S ~[]E, E cmp.Ordered](x S)
type List []int
var list List
slices.Sort(list)
```
次の型方程式が解ければ推論は成功します。ここで `≡` は[「同一である」](https://go.dev/ref/spec#Type_identity)を、`under(S)` は `S` の[基底型](https://go.dev/ref/spec#Underlying_types)を表します。
```
S ≡ List // S ≡ List が真になるようなSを見つける
under(S) ≡ []E // under(S) ≡ []E が真になるようなEを見つける
```
方程式の中の変数にあたるのが型パラメータです。方程式を解くとは、方程式が真になるように、これらの変数（型パラメータ）に対する値（型引数）を見つけることを意味します。このように捉えることで、推論に流れ込む情報を書き下せる形式的な枠組みが手に入り、型推論の問題がより扱いやすくなります。
### 型の関係を正確に扱う
ここまでは単純に、型は同一でなければならないという話をしてきました。しかし実際のGoのコードにとって、それは強すぎる要件です。先ほどの例では、`S` は `List` と同一である必要はなく、むしろ `List` が `S` に[代入可能](https://go.dev/ref/spec#Assignability)でなければなりません。同様に、`S` は対応する型制約を[満たさ](https://go.dev/ref/spec#Satisfying_a_type_constraint)なければなりません。`:≡` と `∈` と書く専用の演算子を使うことで、型方程式をより正確に定式化できます。
```
S :≡ List // ListはSに代入可能
S ∈ ~[]E // Sは制約 ~[]E を満たす
E ∈ cmp.Ordered // Eは制約 cmp.Ordered を満たす
```
一般に、型方程式には3つの形があると言えます。2つの型が同一でなければならない、ある型が別の型に代入可能でなければならない、あるいはある型が型制約を満たさなければならない、の3つです。
```
X ≡ Y // XとYは同一でなければならない
X :≡ Y // YはXに代入可能
X ∈ Y // Xは制約Yを満たす
```
（補足: GopherConの講演では、`:≡` の代わりに `≡`A、`∈` の代わりに `≡`C という記号を使っていました。`:≡` のほうが代入の関係をより明確に想起させ、`∈` は型パラメータが表す型がその制約の[型集合](https://go.dev/ref/spec#Interface_types)の要素でなければならないことを直接的に表していると私たちは考えています。）
### 型方程式の由来
ジェネリック関数の呼び出しでは、明示的な型引数が与えられることもありますが、多くの場合は推論できることを期待します。また、通常の関数引数もあるのが普通です。明示的な型引数はそれぞれ、（自明な）型方程式を1つもたらします。コードにそう書いてある以上、その型パラメータは型引数と同一でなければならない、というものです。通常の関数引数もそれぞれ別の型方程式をもたらします。その関数引数は対応する関数パラメータに代入可能でなければならない、というものです。そして最後に、それぞれの型制約も、どのような型がその制約を満たすかを制限することで型方程式をもたらします。
これらを合わせると、`n` 個の型パラメータと `m` 個の型方程式が生まれます。基本的な高校数学の代数とは違い、型方程式が解けるために `n` と `m` が一致している必要はありません。たとえば、次のたった1つの方程式から、2つの型パラメータの型引数を推論できます。
```go
map[K]V ≡ map[int]string // K ➞ int, V ➞ string (n = 2, m = 1)
```
これらの型方程式の由来を、それぞれ順番に見ていきましょう。
#### 1. 型引数による型方程式
次のような型パラメータの宣言と
```go
func f[…, P constraint, …]…
```
明示的に与えられた型引数
```go
f[…, A, …]…
```
があるとき、次の型方程式が得られます。
```
P ≡ A
```
これは `P` について自明に解けます。`P` は `A` でなければならず、`P ➞ A` と書きます。言い換えると、ここでは何もすることがありません。網羅性のためにそれぞれの型方程式を書き下すことはできますが、実際にはGoコンパイラは型パラメータを型引数へと全体にわたって単純に置き換えるだけで、その後それらの型パラメータは消え去り、私たちはそれらのことを忘れてかまいません。
#### 2. 代入による型方程式
関数パラメータ `p` に渡される関数引数 `x` それぞれについて
```go
f(…, x, …)
```
`p` または `x` が型パラメータを含む場合、`x` の型は `p` の型に代入可能でなければなりません。これは次の方程式で表せます。
```
𝑻(p) :≡ 𝑻(x)
```
ここで `𝑻(x)` は「`x` の型」を意味します。`p` にも `x` にも型パラメータが含まれていなければ、解くべき型変数は存在しません。この方程式は、代入が有効なGoのコードであれば真になり、無効なコードであれば偽になるだけです。このため、型推論は関与する関数（複数の場合も含む）の型パラメータを含む型のみを考慮します。
Go 1.21以降では、（関数呼び出しではなく）具体化されていない、あるいは部分的にしか具体化されていない関数を、次のように関数型の変数に代入することもできるようになりました。
```go
// slicesパッケージより
// func Sort[S ~[]E, E cmp.Ordered](x S)
var intSort func([]int) = slices.Sort
```
パラメータの受け渡しと同様に、このような代入も対応する型方程式をもたらします。この例では次のようになります。
```
𝑻(intSort) :≡ 𝑻(slices.Sort)
```
簡略化すると
```
func([]int) :≡ func(S)
```
これに加えて、`slices.Sort` の `S` と `E` の制約に関する方程式も一緒に得られます（後述）。
#### 3. 制約による型方程式
最後に、型引数を推論したい型パラメータ `P` それぞれについて、その型パラメータは制約を満たさなければならないため、制約から型方程式を取り出せます。次の宣言があるとき、
```go
func f[…, P constraint, …]…
```
次の方程式を書き下せます。
```
P ∈ constraint
```
ここで `∈` は「制約を満たさなければならない」ことを意味し、これは（ほぼ）制約の型集合の要素であることと同じです。後で見るように、一部の制約（`any` など）は役に立たなかったり、実装上の制限から現在使えなかったりします。そのような場合、推論はそれぞれの方程式を単に無視します。
### 型パラメータと方程式は複数の関数にまたがることがある
Go 1.18では、推論される型パラメータはすべて同じ関数由来のものでなければなりませんでした。具体的には、ジェネリックで、具体化されていない、あるいは部分的にしか具体化されていない関数を、関数の引数として渡したり、（関数型の）変数に代入したりすることはできませんでした。
前述の通り、Go 1.21ではこうしたケースでも型推論が機能するようになりました。たとえば、次のジェネリック関数は
```go
func myEq[P comparable](x, y P) bool { return x == y }
```
関数型の変数に代入できます。
```go
var strEq func(x, y string) bool = myEq // myEq[string] を使うのと同じ
```
`myEq` が完全に具体化されていなくても、型推論によって `P` の型引数は `string` でなければならないと推論されます。
さらに、ジェネリック関数は、具体化されていない、あるいは部分的にしか具体化されていない状態のまま、別の（それ自身もジェネリックかもしれない）関数への引数として使うこともできます。
```go
// slicesパッケージより
// func CompactFunc[S ~[]E, E any](s S, eq func(E, E) bool) S
type List []int
var list List
result := slices.CompactFunc(list, myEq) // slices.CompactFunc[List, int](list, myEq[int]) を使うのと同じ
```
最後の例では、型推論によって `CompactFunc` と `myEq` の型引数が決定されています。より一般には、任意の数の関数に由来する型パラメータを推論する必要が生じることがあります。複数の関数が関与する場合、型方程式もまた複数の関数に由来し、あるいはそれらに関わることがあります。`CompactFunc` の例では、最終的に3個の型パラメータと5個の型方程式が得られます。
```
型パラメータと制約:
S ~[]E
E any
P comparable
明示的な型引数:
なし
型方程式:
S :≡ List
func(E, E) bool :≡ func(P, P) bool
S ∈ ~[]E
E ∈ any
P ∈ comparable
解:
S ➞ List
E ➞ int
P ➞ int
```
### 束縛された型パラメータと自由な型パラメータ
ここまでで型方程式のさまざまな由来について理解が深まりましたが、その方程式をどの型パラメータについて解くのかは、まだあまり厳密に説明していませんでした。別の例を考えてみましょう。次のコードでは、`sortedPrint` の関数本体がソート処理のために `slices.Sort` を呼び出しています。`sortedPrint` と `slices.Sort` はどちらも型パラメータを宣言しているため、両方ともジェネリック関数です。
```go
// slicesパッケージより
// func Sort[S ~[]E, E cmp.Ordered](x S)
// sortedPrintは与えられたリストの要素をソートして表示する。
func sortedPrint[F any](list []F) {
slices.Sort(list) // 𝑻(list) は []F
… // listを表示する
}
```
ここでは `slices.Sort` の呼び出しに対する型引数を推論したいとします。`list` を `slices.Sort` のパラメータ `x` に渡すことで、次の方程式が生まれます。
```
𝑻(x) :≡ 𝑻(list)
```
これは次と同じです。
```
S :≡ []F
```
この方程式には `S` と `F` という2つの型パラメータがあります。どちらについて型方程式を解く必要があるのでしょうか。呼び出されている関数は `Sort` なので、私たちが気にするのはその型パラメータである `S` であって、`F` ではありません。`S` は `Sort` によって宣言されているため、`S` は `Sort` に_束縛_されていると言います。この方程式で意味を持つ型変数は `S` です。対照的に、`F` は `sortedPrint` に束縛（宣言）されています。`F` は `Sort` に対して_自由_であると言います。`F` はすでに与えられた、それ自身の型を持っています。その型が何であるかは（具体化の時点で決まる）`F` そのものです。この方程式において、`F` はすでに与えられている、いわば_型定数_です。
型方程式を解くときには、私たちが呼び出そうとしている関数（ジェネリック関数の代入の場合は代入先の関数）に束縛された型パラメータについて、常に解を求めます。
## 型方程式を解く
関連する型パラメータと型方程式を集める方法が確立できたところで、残るピースはもちろん、その方程式を解くためのアルゴリズムです。ここまでのさまざまな例から、`X ≡ Y` を解くとは、単に型 `X` と `Y` を再帰的に比較し、その過程で `X` と `Y` の中に現れうる型パラメータに適切な型引数を決定していくことにほかならない、ということがおそらく明らかになったでしょう。目標は型 `X` と `Y` を同一にすることです。このマッチングの処理は[_単一化_](https://en.wikipedia.org/wiki/Unification_(computer_science))と呼ばれます。
[型の同一性のルール](https://go.dev/ref/spec#Type_identity)は、型をどのように比較するかを教えてくれます。束縛された型パラメータは型変数の役割を果たすため、それらが他の型とどのようにマッチングされるかを規定する必要があります。ルールは次の通りです。
* 型パラメータ `P` に推論済みの型があれば、`P` はその型を表す。
* 型パラメータ `P` に推論済みの型がなく、別の型 `T` とマッチングされた場合、`P` はその型に設定される: `P ➞ T`。このとき、型 `T` は `P` に対して推論されたと言う。
* `P` が別の型パラメータ `Q` とマッチングされ、`P` にも `Q` にもまだ推論済みの型がない場合、`P` と `Q` は単一化される。
2つの型パラメータの単一化とは、それらが結び付けられ、以後は両方とも同じ型パラメータの値を表すようになることを意味します。`P` または `Q` のどちらか一方が型 `T` とマッチングされると、`P` と `Q` の両方が同時に `T` に設定されます（一般に、任意の数の型パラメータをこの方法で単一化できます）。
最後に、2つの型 `X` と `Y` が異なる場合、その方程式を真にすることはできず、解くことに失敗します。
### 型の同一性のための単一化
いくつか具体的な例を見ればこのアルゴリズムが明らかになるはずです。3つの束縛された型パラメータ `A`、`B`、`C` を含む2つの型 `X` と `Y` を考えます。これらはすべて型方程式 `X ≡ Y` に現れます。目標はこの方程式を型パラメータについて解くこと、つまり `X` と `Y` が同一になり方程式が真になるように、それぞれに適切な型引数を見つけることです。
```go
X: map[A]struct{i int; s []B}
Y: map[string]struct{i C; s []byte}
```
単一化は、頂点から始めて `X` と `Y` の構造を再帰的に比較することで進みます。2つの型の構造だけに注目すると、次のようになります。
```go
map[…]… ≡ map[…]…
```
`…` は、この段階では無視しているそれぞれのマップのキー型と値型を表しています。両辺ともマップなので、ここまでは型は一致しています。単一化は再帰的に進み、まずキー型同士、つまり `X` のマップの `A` と `Y` のマップの `string` を比較します。対応するキー型は同一でなければならないため、そこから `A` の型引数は `string` でなければならないとただちに推論できます。
```go
A ≡ string => A ➞ string
```
続いてマップの値型に進むと、次に行き着きます。
```go
struct{i int; s []B} ≡ struct{i C; s []byte}
```
両辺とも構造体なので、単一化は構造体のフィールドについて進みます。フィールドが同じ順序で、同じ名前を持ち、かつ型が同一であれば、構造体は同一とみなされます。最初のフィールドの組は `i int` と `i C` です。名前は一致しており、`int` は `C` と単一化されなければならないため、次のようになります。
```go
int ≡ C => C ➞ int
```
この再帰的な型のマッチングは、2つの型の木構造がすべて走査されるか、矛盾が現れるまで続きます。この例では、最終的に次のようになります。
```go
[]B ≡ []byte => B ≡ byte => B ➞ byte
```
すべてがうまくいき、単一化によって次の型引数が推論されます。
```
A ➞ string
B ➞ byte
C ➞ int
```
### 構造の異なる型の単一化
今度は先ほどの例を少し変えたものを考えてみましょう。ここでは `X` と `Y` は同じ型構造を持っていません。型の木構造を再帰的に比較していくと、`A` の型引数の推論には単一化は成功しますが、マップの値型が異なっているため単一化は失敗します。
```go
X: map[A]struct{i int; s []B}
Y: map[string]bool
```
`X` と `Y` はどちらもマップ型なので、単一化は先ほどと同様にキー型から再帰的に進みます。次に行き着きます。
```go
A ≡ string => A ➞ string
```
これも先ほどと同じです。しかしマップの値型に進むと、次のようになります。
```go
struct{…} ≡ bool
```
`struct` 型は `bool` と一致しません。異なる型同士であるため単一化（したがって型推論）は失敗します。
### 型引数が矛盾する型の単一化
別の種類の矛盾は、異なる型が同じ型パラメータに対してマッチングされたときに生じます。ここでも最初の例の別バージョンを考えますが、今度は型パラメータ `A` が `X` の中に2回、`C` が `Y` の中に2回現れます。
```go
X: map[A]struct{i int; s []A}
Y: map[string]struct{i C; s []C}
```
再帰的な型の単一化は最初のうちはうまくいき、型パラメータと型の次のような組が得られます。
```go
A ≡ string => A ➞ string // マップのキー型
int ≡ C => C ➞ int // 構造体の最初のフィールド型
```
構造体の2番めのフィールド型に着くと、次のようになります。
```go
[]A ≡ []C => A ≡ C
```
`A` にも `C` にもすでに型引数が推論されているため、両者はそれぞれの型引数、すなわち `string` と `int` を表します。これらは異なる型なので、`A` と `C` は決して一致し得ません。単一化、したがって型推論は失敗します。
### その他の型の関係
単一化は、型の同一性を目標とする `X ≡ Y` という形の型方程式を解きます。では `X :≡ Y` や `X ∈ Y` はどうでしょうか。
ここでは、いくつかの観察が助けになります。型推論の仕事は、省略された型引数の型を見つけることだけです。型推論の後には必ず型や関数の[具体化](https://go.dev/ref/spec#Instantiations)が続き、そこで各型引数が実際にそれぞれの型制約を満たしているかが確認されます。さらに、ジェネリック関数の呼び出しの場合、コンパイラは関数引数が対応する関数パラメータに代入可能かどうかも確認します。コードが有効であるためには、これらすべての段階が成功しなければなりません。
型推論が十分に正確でない場合、本来型が存在しないところに（誤った）型引数を推論してしまうことがあります。その場合、具体化か引数の受け渡しのいずれかが失敗します。いずれにせよコンパイラはエラーメッセージを出します。ただ、そのエラーメッセージが多少異なるものになるだけです。
この気づきによって、`:≡` と `∈` という型の関係については、多少大まかに扱う余地が生まれます。具体的には、これらを単純化して、ほとんど `≡` と同じように扱えるようにできます。この単純化の狙いは、型方程式からできる限り多くの型情報を引き出すことです。つまり、それが可能である以上、厳密な実装では失敗してしまうようなケースでも型引数を推論できるようにすることです。
### X :≡ Y の単純化
Goの代入可能性のルールはかなり複雑ですが、実際にはほとんどの場合、型の同一性かそれをわずかに変えたものだけで済ませられます。型推論の後には型の具体化と関数呼び出しが必ず続くからこそ、可能性のある型引数さえ見つかればそれで十分なのです。推論が本来見つけるべきでない型引数を見つけてしまっても、それは後で捕捉されます。そこで、代入可能性についてマッチングする際には、単一化のアルゴリズムに次の調整を加えます。
* 名前付き（定義された）型がリテラル型とマッチングされる場合、代わりに両者の基底型が比較される。
* チャンネル型を比較する際には、チャンネルの方向は無視される。
さらに、代入の向きは無視されます。`X :≡ Y` は `Y :≡ X` と同じように扱われます。
これらの調整は型構造の最上位でのみ適用されます。たとえば、Goの[代入可能性のルール](https://go.dev/ref/spec#Assignability)によれば、名前付きのマップ型は名前のないマップ型に代入できますが、キー型と要素型は依然として同一でなければなりません。この変更によって、代入可能性のための単一化は、型の同一性のための単一化を（わずかに）変えたものになります。次の例でこれを説明します。
先ほどの `List` 型（`type List []int` として定義）の値を、`E` が束縛された型パラメータである（つまり、呼び出されているジェネリック関数によって宣言されている）型 `[]E` の関数パラメータに渡す場合を考えます。これは型方程式 `[]E :≡ List` をもたらします。この2つの型を単一化しようとすると、`[]E` と `List` を比較する必要がありますが、この2つは同一ではなく、単一化の動作を何も変えなければ失敗してしまいます。しかし、ここでは代入可能性のための単一化を行っているため、この最初のマッチングは厳密である必要はありません。名前付き型 `List` の基底型に進んでも問題はありません。最悪の場合、誤った型引数を推論してしまうこともありますが、それは後で代入がチェックされる際にエラーとして検出されます。最良の場合には、役に立つ正しい型引数が見つかります。この例では、厳密ではない単一化は成功し、`E` に対して正しく `int` が推論されます。
### X ∈ Y の単純化
制約の充足関係を単純化できることは、制約が非常に複雑になり得ることを考えるといっそう重要です。
ここでもやはり、制約の充足は具体化の時点でチェックされるため、ここでの狙いは、可能な範囲で型推論を手助けすることです。これは典型的には、型パラメータの構造がわかっている状況です。たとえば、それがスライス型でなければならないとわかっていて、そのスライスの要素型を知りたい場合です。たとえば `[P ~[]E]` という形の型パラメータリストは、`P` が何であれ、その基底型は `[]E` という形でなければならないことを教えてくれます。これはまさに、その制約が[コア型](https://go.dev/ref/spec#Core_types)を持つ状況です。
したがって、次の形の方程式があり、
```
P ∈ constraint // あるいは
P ∈ ~constraint
```
`core(constraint)`（それぞれ `core(~constraint)`）が存在するならば、この方程式は次のように単純化できます。
```
P ≡ core(constraint)
under(P) ≡ core(~constraint) // それぞれの場合
```
それ以外のすべての場合、制約を含む型方程式は無視されます。
### 推論された型の展開
単一化が成功すると、型パラメータから推論された型引数へのマッピングが得られます。しかし、単一化だけでは、推論された型に束縛された型パラメータが含まれていないことまでは保証されません。なぜそうなるのかを見るために、`int` 型の引数 `x` 1つだけで呼び出される、次のジェネリック関数 `g` を考えてみましょう。
```go
func g[A any, B []C, C *A](x A) { … }
var x int
g(x)
```
`A` の型制約は `any` で、これはコア型を持たないため無視します。残りの型制約にはコア型があり、それぞれ `[]C` と `*A` です。`g` に渡される引数と合わせて、細かな単純化を行うと、型方程式は次のようになります。
```
A :≡ int
B ≡ []C
C ≡ *A
```
それぞれの方程式は型パラメータを、型パラメータではない型と対峙させているだけなので、単一化がすべきことはほとんどなく、ただちに次のように推論されます。
```
A ➞ int
B ➞ []C
C ➞ *A
```
しかしこれでは、推論された型の中に型パラメータ `A` と `C` が残ってしまい、役に立ちません。高校数学の代数と同じように、ある変数 `x` について方程式を1つ解いたら、残りの方程式全体でその `x` を求めた値に置き換える必要があります。この例では、まず `[]C` の中の `C` を、`C` について推論された型（「値」）である `*A` に置き換えると、次のようになります。
```
A ➞ int
B ➞ []*A // CをA*で置換
C ➞ *A
```
さらに2段階の置き換えを行い、推論された型 `[]*A` と `*A` の中の `A` を、`A` について推論された型である `int` に置き換えます。
```
A ➞ int
B ➞ []*int // Aをintで置換
C ➞ *int // Aをintで置換
```
ここでようやく推論が完了します。そして高校数学の代数と同じように、これがうまくいかないこともあります。次のような状況に行き着くこともあり得ます。
```
X ➞ Y
Y ➞ *X
```
1回置換を行うと、次のようになります。
```
X ➞ *X
```
これを続けていくと、`X` に対して推論される型はどんどん大きくなっていきます。
```
X ➞ **X // XをX*で置換
X ➞ ***X // XをX*で置換
// 以下同様
```
型推論は、展開の過程でこのような循環を検出し、エラーを報告します（つまり失敗します）。
## 無型定数
ここまでで、型推論が単一化によって型方程式を解き、続いてその結果を展開することでどのように機能するかを見てきました。しかし、もし型がまったくなかったらどうなるでしょうか。関数の引数が無型定数だったらどうなるでしょうか。
別の例がこの状況を理解する助けになります。任意の個数の引数を取り、それらすべてが同じ型でなければならない関数 `foo` を考えます。`foo` は、`int` 型の変数 `x` を含むさまざまな無型定数の引数とともに呼び出されます。
```go
func foo[P any](...P) {}
var x int
foo(x) // P ➞ int, foo[int](x) と同じ
foo(x, 2.0) // P ➞ int, 2.0は精度を失わずにintに変換できる
foo(x, 2.1) // P ➞ int だが、引数の受け渡しは失敗する: 2.1はintに代入できない
```
型推論では、型付きの引数が無型の引数よりも優先されます。無型定数が推論の対象として考慮されるのは、それが割り当てられる型パラメータにまだ推論済みの型がない場合だけです。`foo` へのこれら最初の3回の呼び出しでは、変数 `x` が `P` の推論される型を決定します。それは `x` の型である `int` です。この場合、無型定数は型推論において無視され、これらの呼び出しは `foo` が明示的に `int` で具体化されたのとまったく同じように振る舞います。
`foo` が無型定数の引数だけで呼び出されると、話はもう少し興味深くなります。この場合、型推論は無型定数の[デフォルト型](https://go.dev/ref/spec#Constants)を考慮します。簡単なおさらいとして、Goで取り得るデフォルト型を挙げておきます。
```
例 定数の種類 デフォルト型 順序
true 真偽値定数 bool
42 整数定数 int リストの先頭側
'x' rune定数 rune |
3.1416 浮動小数点定数 float64 v
-1i 複素数定数 complex128 リストの末尾側
"gopher" 文字列定数 string
```
この情報をふまえて、次の関数呼び出しを考えてみましょう。
```go
foo(1, 2) // P ➞ int（1と2のデフォルト型）
```
無型定数の引数 `1` と `2` はどちらも整数定数で、そのデフォルト型は `int` です。したがって `foo` の型パラメータ `P` に対して推論されるのは `int` です。
もし異なる種類の定数（たとえば無型の整数定数と浮動小数点定数）が同じ型変数を奪い合う場合、デフォルト型が異なることになります。Go 1.21より前は、これは矛盾とみなされエラーになっていました。
```go
foo(1, 2.0) // Go 1.20: 推論エラー: デフォルト型のintとfloat64が一致しない
```
この挙動は使い勝手があまりよくなく、式の中での無型定数の挙動とも異なっていました。たとえば、Goでは定数式 `1 + 2.0` が許されており、その結果はデフォルト型が `float64` である浮動小数点定数 `3.0` になります。
Go 1.21ではこれに合わせて挙動が変更されました。現在では、複数の無型の数値定数が同じ型パラメータに対してマッチングされた場合、`int`、`rune`、`float64`、`complex` というリストのより後方に現れるデフォルト型が選ばれます。これは[定数式](https://go.dev/ref/spec#Constant_expressions)のルールに一致するものです。
```go
foo(1, 2.0) // Go 1.21: P ➞ float64（1と2.0のうち大きいほうのデフォルト型。1 + 2.0 と同じ挙動）
```
## 特殊な状況
ここまでで型推論の全体像はつかめました。しかし、注目に値する重要な特殊状況がいくつかあります。
### パラメータの順序への依存
1つめは、パラメータの順序への依存に関するものです。型推論に求めたい重要な性質の1つは、関数パラメータの順序（およびその関数の各呼び出しにおける対応する引数の順序）にかかわらず、同じ型が推論されることです。
可変長引数を取る `foo` 関数をもう一度考えてみましょう。引数 `s` と `t` を渡す順序にかかわらず、`P` に対して推論される型は同じであるべきです（[playground](https://go.dev/play/p/sOlWutKnDFc)）。
```go
func foo[P any](...P) (x P) {}
type T struct{}
func main() {
var s struct{}
var t T
fmt.Printf("%T\n", foo(s, t))
fmt.Printf("%T\n", foo(t, s)) // パラメータの順序にかかわらず同じ結果になるはず
}
```
`foo` の呼び出しから、関連する型方程式を取り出せます。
```
𝑻(x) :≡ 𝑻(s) => P :≡ struct{} // 方程式1
𝑻(x) :≡ 𝑻(t) => P :≡ T // 方程式2
```
残念ながら、`:≡` の単純化された実装は順序への依存を生んでしまいます。
単一化が方程式1から始まる場合、`P` は `struct{}` とマッチングされます。`P` にはまだ推論済みの型がないため、単一化は `P ➞ struct{}` と推論します。その後、方程式2で型 `T` を見ると、単一化は `T` の基底型である `struct{}` に進み、`P` と `under(T)` が単一化され、単一化、したがって推論は成功します。
逆に、単一化が方程式2から始まる場合、`P` は `T` とマッチングされます。`P` にはまだ推論済みの型がないため、単一化は `P ➞ T` と推論します。その後、方程式1で `struct{}` を見ると、単一化は `P` に対して推論された型 `T` の基底型に進みます。その基底型は `struct{}` であり、これは方程式1の `struct` と一致するため、単一化、したがって推論は成功します。
その結果、単一化が2つの型方程式を解く順序によって、推論される型は `struct{}` になったり `T` になったりします。これはもちろん満足のいくものではありません。コードのリファクタリングや整理のときに引数の並び順が入れ替わっただけで、プログラムが突然コンパイルできなくなってしまうことがあり得るからです。
### 順序への非依存性の回復
幸い、この対処法はかなり単純です。必要なのは、いくつかの状況でのちょっとした補正だけです。
具体的には、単一化が `P :≡ T` を解いていて、かつ
* `P` がすでに型 `A` を推論している型パラメータである: `P ➞ A`
* `A :≡ T` が真である
* `T` が名前付き型である
という条件を満たす場合、`P` に対して推論された型を `T` に設定します: `P ➞ T`
これにより、選択の余地がある場合には、その名前付き型が `P` とのマッチングの中でどの時点で現れたか（つまり、型方程式がどの順序で解かれたか）にかかわらず、`P` は必ずその名前付き型になります。なお、異なる名前付き型が同じ型パラメータに対してマッチングされた場合には、異なる名前付き型は定義上同一ではないため、常に単一化は失敗することに注意してください。
チャンネルやインターフェースについても同様の単純化を行っているため、それらにも同様の特別な処理が必要です。たとえば、代入可能性のための単一化ではチャンネルの方向を無視しているため、その結果、引数の順序によって単方向のチャンネルが推論されたり双方向のチャンネルが推論されたりすることがあります。インターフェースについても同様の問題が起こります。ここではこれらについては触れません。
先ほどの例に戻ると、単一化が方程式1から始まる場合、これまでと同じように `P ➞ struct{}` と推論されます。方程式2に進むと、これもこれまでと同じように単一化は成功しますが、ここでちょうど補正が必要になる条件がそろっています。`P` はすでに型（`struct{}`）を持つ型パラメータであり、`struct{} :≡ T` は真であり（`struct{} ≡ under(T)` が真であるため）、`T` は名前付き型です。そのため、単一化は補正を行い `P ➞ T` を設定します。結果として、単一化の順序にかかわらず、どちらの場合も結果は同じ（`T`）になります。
### 自己再帰する関数
素朴な実装の推論で問題を引き起こす別のシナリオが、自己再帰する関数です。浮動小数点数の引数に対しても動作するように定義された、ジェネリックな階乗関数 `fact` を考えてみましょう（[playground](https://go.dev/play/p/s3wXpgHX6HQ)）。なお、これは[ガンマ関数](https://en.wikipedia.org/wiki/Gamma_function)の数学的に正しい実装ではなく、単なる便宜的な例であることに注意してください。
```go
func fact[P ~int | ~float64](n P) P {
if n <= 1 {
return 1
}
return fact(n-1) * n
}
```
ここでのポイントは階乗関数そのものではなく、`fact` が、受け取ったパラメータ `n` と同じ型 `P` を持つ引数 `n-1` を使って自分自身を呼び出しているという点です。この呼び出しでは、型パラメータ `P` は束縛された型パラメータであると同時に自由な型パラメータでもあります。再帰的に呼び出している関数である `fact` によって宣言されているという意味では束縛されていますが、その呼び出しを囲んでいる関数（たまたまこれも `fact` です）によって宣言されているという意味では自由でもあります。
引数 `n-1` をパラメータ `n` に渡すことから生じる方程式は、`P` を自分自身と対峙させます。
```
𝑻(n) :≡ 𝑻(n-1) => P :≡ P
```
単一化は、方程式の両辺に同じ `P` があるのを見ます。両方の型は同一なので単一化は成功しますが、そこから得られる情報はなく、`P` には推論された型がないままです。その結果、型推論は失敗します。
幸い、これに対処するための工夫は単純です。型推論が呼び出される前に、そしてあくまで型推論が（一時的に）使うためだけに、コンパイラはその呼び出しに関わるすべての関数のシグネチャ（本体は除く）の中で型パラメータの名前を付け替えます。これによって関数シグネチャの意味が変わるわけではありません。型パラメータの名前が何であっても、同じジェネリック関数を表すことに変わりはないからです。
この例のために、`fact` のシグネチャにある `P` が `Q` に付け替えられたとしましょう。その効果は、再帰呼び出しを `helper` 関数を介して間接的に行っているのと同じことになります（[playground](https://go.dev/play/p/TLpo-0auWwC)）。
```go
func fact[P ~int | ~float64](n P) P {
if n <= 1 {
return 1
}
return helper(n-1) * n
}
func helper[Q ~int | ~float64](n Q) Q {
return fact(n)
}
```
この名前の付け替え、あるいは `helper` 関数を使うことで、`n-1` を `fact`（それぞれ `helper` 関数）への再帰呼び出しに渡すことから生じる方程式は、次のように変わります。
```
𝑻(n) :≡ 𝑻(n-1) => Q :≡ P
```
この方程式には2つの型パラメータがあります。呼び出されている関数によって宣言された束縛された型パラメータ `Q` と、それを囲む関数によって宣言された自由な型パラメータ `P` です。この型方程式は `Q` について自明に解け、`Q ➞ P` という推論が得られます。これはもちろん私たちが期待する通りのものであり、再帰呼び出しを明示的に具体化することで確認できます（[playground](https://go.dev/play/p/zkUFvwJ54lC)）。
```go
func fact[P ~int | ~float64](n P) P {
if n <= 1 {
return 1
}
return fact[P](n-1) * n
}
```
## 何が足りないか
ここまでの説明で目立って欠けているのが、ジェネリック_型_に対する型推論です。現状、ジェネリック型は常に明示的に具体化しなければなりません。
これにはいくつか理由があります。まず第一に、型の具体化においては、型推論が扱えるのは型引数だけであり、関数呼び出しの場合のような他の引数はありません。その結果、（すべての型パラメータに対して型制約がちょうど1つの型引数しか許さないような病的なケースを除いて）少なくとも1つの型引数を常に与える必要があります。したがって、型に対する型推論が役立つのは、省略されたすべての型引数を型制約から生じる方程式から推論できる、部分的に具体化された型を完成させる場合、つまり少なくとも2つの型パラメータがある場合に限られます。これはあまり一般的なシナリオではないと私たちは考えています。
第二に、こちらのほうがより本質的な理由ですが、型パラメータによってまったく新しい種類の再帰的な型が可能になるということがあります。次のような仮定の型を考えてみましょう。
```go
type T[P T[P]] interface{ … }
```
ここでは `P` の制約が、いままさに宣言されている型そのものになっています。複数の型パラメータが複雑な再帰的な形で互いを参照し合える能力と組み合わさると、型推論ははるかに複雑になり、私たちも現時点でそのすべての含意を完全には理解できていません。とはいえ、循環を検出して、そのような循環が存在しない場合には型推論を進める、ということ自体はそれほど難しくないはずだと考えています。
最後に、単一化はこの記事で先に説明したようないくつかの単純化した仮定のもとで動作しているため、型推論だけでは単純に推論を行うだけの力がない状況もあります。ここでの代表例は、コア型を持たない制約です。もっと洗練されたアプローチを使えば、そういった場合でも型情報を推論できるかもしれません。
これらはいずれも、今後のGoのリリースで段階的な改善が見られるかもしれない領域です。重要なのは、現状の実装で推論が失敗するケースは、まれであるか、あるいは実運用のコードにおいてはさほど重要でないかのいずれかであり、現在の実装が有用なコードのシナリオの大部分をカバーしていると私たちが考えている、ということです。
とはいえ、型推論が本来うまくいくはずだ、あるいはおかしな挙動をしていると思われる状況に出くわしたら、ぜひ[イシューを報告](https://go.dev/issue/new)してください! いつものことですが、Goチームは皆さんからの声を、特にそれがGoをさらによくする助けになるときには、大歓迎です。
By Robert Griesemer