Go言語入門：言語仕様 -Vol.150-

本日は、Go言語の言語仕様について解説しています。

背景

Go言語を学び始めて、公式の「The Go Programming Language Specification(言語仕様書)」を開いてみたものの、「英語で書かれていて読むのが大変…」「専門用語ばかりで何を言っているのかわからない…」と感じたことはありませんか? 実は、多くのGo初心者が同じ壁にぶつかっています。

言語仕様書は、Go言語の「正式な取扱説明書」のような存在です。プログラミング言語がどのように動くのか、どんなルールで書くべきなのかが詳しく書かれていますが、その分、初めて読む人には難しく感じられるのも事実です。

そこでこの記事では、言語仕様書の導入部分を丁寧な日本語訳とともに、初心者の方でも理解しやすい補足説明を加えてお届けします。「強く型付けされている」「ガベージコレクション」「並行プログラミング」といった専門用語も、具体例を交えながらわかりやすく解説していきます。

言語仕様書は難しそうに見えますが、一つひとつの概念を丁寧に読み解いていけば、必ず理解できます。一緒に、Go言語の基礎をしっかり学んでいきましょう!

型単一化（type unification）のルール

型単一化のルールは、2つの型が単一化されるかどうか、また、どのように単一化されるかを記述するものです。その正確な詳細はGoの実装にとって重要であり、エラーメッセージの具体的な内容（コンパイラが型推論エラーを報告するのか、それとも別のエラーを報告するのか、など）に影響し、また、変わったコード状況で型推論が失敗する理由を説明することがあります。しかし大筋では、Goのコードを書く際にこれらのルールは無視して構いません。型推論はおおむね「期待どおりに動作する」ように設計されており、単一化のルールはそれに合わせて細かく調整されています。

型単一化は「マッチングモード」によって制御され、これは厳密（exact）か緩い（loose）のいずれかです。単一化が複合型の構造を再帰的に下降していくとき、型の要素に使われるマッチングモード（要素マッチングモード）は、マッチングモードと同じままです。ただし、2つの型が代入可能性（≡A）のために単一化される場合は例外です。この場合、マッチングモードはトップレベルでは緩い（loose）ですが、要素型については厳密（exact）に変わります。これは、型が代入可能であるために同一である必要はない、という事実を反映しています。

束縛型パラメータ（bound type parameter）でない2つの型は、次の条件のいずれかが真であるとき、厳密に単一化されます。

• 両方の型が同一である。
• 両方の型が同一の構造を持ち、それらの要素型が厳密に単一化される。
• ちょうど一方の型が束縛されていない（unbound）型パラメータであり、その型集合内のすべての型が、≡A の単一化ルール（トップレベルでは緩い単一化、要素型では厳密な単一化）に従ってもう一方の型と単一化される。

両方の型が束縛型パラメータである場合、それらは次のとき、与えられたマッチングモードに従って単一化されます。

• 両方の型パラメータが同一である。
• 型パラメータのうち、既知の型引数を持つものが多くとも1つである。この場合、2つの型パラメータは結合（join）されます。すなわち、両方が同じ型引数を表すようになります。どちらの型パラメータもまだ既知の型引数を持たない場合、一方の型パラメータについて将来推論される型引数が、両方について同時に推論されます。
• 両方の型パラメータが既知の型引数を持ち、それらの型引数が、与えられたマッチングモードに従って単一化される。

単一の束縛型パラメータ P と別の型 T は、次のとき、与えられたマッチングモードに従って単一化されます。

• P が既知の型引数を持たない。この場合、T が P の型引数として推論されます。
• P が既知の型引数 A を持ち、A と T が与えられたマッチングモードに従って単一化され、かつ次の条件のいずれかが真である。
  • A と T の両方がインターフェース型である場合：このとき、A と T の両方が定義された型でもあるなら、それらは同一でなければなりません。そうでなく、どちらも定義された型でないなら、それらは同じ数のメソッドを持たなければなりません（A と T の単一化によって、メソッドが一致することはすでに確立されています）。
  • A と T のどちらもインターフェース型でない場合：このとき、T が定義された型であるなら、T が A に代わって P の推論された型引数となります。

最後に、束縛型パラメータでない2つの型は、次のとき、（要素マッチングモードに従って）緩く単一化されます。

• 両方の型が厳密に単一化される。
• 一方の型が定義された型であり、もう一方の型が型リテラル（ただしインターフェースではない）であって、それらの基底型が要素マッチングモードに従って単一化される。
• 両方の型が（型パラメータではない）インターフェースであり、同一の型項を持ち、両方が（あるいはどちらも）事前宣言された型 comparable を埋め込んでおり、対応するメソッド型が厳密に単一化され、かつ一方のインターフェースのメソッドセットが他方のインターフェースのメソッドセットの部分集合である。
• ちょうど一方の型が（型パラメータではない）インターフェースであり、2つの型の対応するメソッドが要素マッチングモードに従って単一化され、かつそのインターフェースのメソッドセットが他方の型のメソッドセットの部分集合である。
• 両方の型が同じ構造を持ち、それらの要素型が要素マッチングモードに従って単一化される。

解説

結論：この節は、ジェネリクスの「型推論」が裏側でどう型を突き合わせているかという、コンパイラ実装者向けの最も深い内部ルール。原文自身が「コードを書くときは無視してよい」と明言している。初心者は『型推論を支える内部の仕組みがある』とだけ知っておけば十分で、細部を理解する必要はない。

率直に言って、この節はGo言語仕様の中でも最も抽象的で、最も実務から遠い部分です。前置きとして原文自身がはっきり「by and large these rules can be ignored when writing Go code（大筋では、コードを書く際これらのルールは無視して構わない）」と述べています。これは仕様書としては異例なほど明確な「読み飛ばし許可」です。以下では、何の話をしているのかのイメージだけを掴めるよう、噛み砕いて説明します。

そもそも「型単一化」とは何の話か

これは ジェネリクス（Go 1.18で導入）の「型推論」の裏側 の話です。

ジェネリクスでは、型を後から決められる関数を書けます。そして多くの場合、その型をプログラマが明示しなくても、Goが自動で型を推論してくれます。

func Max[T int | float64](a, b T) T { /* ... */ }

Max(3, 5) // T が int だと "推論" される。Max[int](3, 5) と書かなくてよい

この「3 と 5 を見て、T は int だな」と判断する仕組みが型推論です。そして**型推論が内部で行っている中心的な作業が「型単一化（type unification）」**です。

単一化とは、ざっくり言えば**「2つの型を突き合わせて、矛盾なく一致させられるか、一致させるなら未知の型を何だと確定すべきか」を決める照合作業**です。方程式に例えると、T = int という等式を解いて T の中身を求めるような作業です。a の位置に 3（int）が来たから、T という「未知数」は int だと解ける、というイメージです。

exact（厳密）と loose（緩い）の2モード

この節の骨格は、単一化に2つの厳しさのモードがあるという点です。

モード	意味
exact（厳密）	型がぴったり同一でないと一致とみなさない
loose（緩い）	完全に同一でなくても、代入可能などの条件で一致とみなす

なぜ2モードあるのか。それは**「型は、まったく同一でなくても代入できることがある」**からです。原文の言葉どおり「types don’t have to be identical to be assignable（代入可能であるために同一である必要はない）」のです。

たとえば、ある具体型をインターフェース型の変数に代入できます。両者は同一の型ではありませんが、代入は通ります。型推論もこうした「ゆるい一致」を扱う必要があるため、状況に応じて loose と exact を使い分けます。

面白いのが、原文の「トップレベルは loose だが、要素型に降りると exact に切り替わる」という挙動です。これは入れ子構造（スライスの中の型、マップの値の型など）を再帰的にたどる際、外側は緩く許すが、内側の部品同士はきっちり一致させるという設計です。建物に例えると、「建物全体の用途は多少幅を持たせて一致を認めるが、内部の部品の規格はぴったり合っていなければならない」という二段構えの検査です。

残りの大量の条件分岐について

この節の大半は、「両方が束縛型パラメータのとき」「片方だけが型パラメータのとき」「両方がインターフェースのとき」…といったケースごとの細かい一致条件の列挙です。

専門用語をいくつか補足します。

• 型パラメータ（type parameter）：ジェネリクスの [T ...] の T のような「後で型が入る穴」のこと。
• 束縛（bound）／束縛されていない（unbound）：その穴がすでに何らかの型に紐づけられているか、まだ自由（未確定）か、の区別。
• 型引数（type argument）：穴に実際に入る具体的な型（Max[int] の int）。
• メソッドセット：ある型が持つメソッドの一覧。インターフェースの一致判定で使われる。
• 基底型（underlying type）／定義された型（defined type）：type MyInt int のように名前を付けた型（定義された型）と、その素の正体である int（基底型）の区別。

これらの条件は、要するに**「未知の穴（型パラメータ）に型を当てはめていく際の、あらゆる場合分けと、矛盾が起きないかのチェックルール」**を網羅的に書き下したものです。たとえば「ある穴 P にまだ型が入っていなければ、相手の型 T をそのまま入れる」「すでに A が入っているなら、A と T が両立するか確かめ、条件次第でより具体的な方に差し替える」といった具合です。

パズルに例えると、複数の空欄にピースをはめていくとき、「空欄にまだ何も無ければそのピースを置く」「すでに何か置いてあれば、新しいピースと食い違わないか確認し、より形のはっきりしたピースを優先する」というルール集だと思ってください。

初心者が取るべきスタンス

正直に言って、この節を理解しようと時間をかける必要はありません。理由は3つです。

第一に、原文自身が無視してよいと明言しています。第二に、これはコンパイラを実装する側のための規定であって、コンパイラを使う側には見えない内部処理です。第三に、型推論は「期待どおり動く」ように調整されているため、普段は推論が裏で何をしているか意識せずにジェネリクスを使えます。

// 普段はこう書くだけで、上記の複雑なルールは全部コンパイラが裏でやってくれる
nums := []int{3, 1, 4, 1, 5}
m := slices.Max(nums) // T が int だと自動推論される。仕組みを知らなくても使える

この節が役に立つのは、ごく稀に**「なぜか型推論が失敗してコンパイルエラーになる」変わった状況に出くわし、その理由を深掘りしたいとき**くらいです。そうした場面に実際に遭遇してから読み返せば十分で、今の段階で身構える必要はまったくありません。

---

補足：これでGo言語仕様の型推論まわりの最も深い部分まで到達しました。型単一化のルールは「ジェネリクスの型推論という便利機能を、曖昧さなく厳密に定義するための土台」です。私たちが普段 slices.Max(nums) と気軽に書けるのは、この見えないルール群がその下で矛盾なく型を解決してくれているおかげ、という関係です。仕様を「使う立場」では意識不要ですが、「Goがいかに緻密に設計されているか」を物語る節として眺めておくと、言語への理解が一段深まります。

おわりに 

本日は、Go言語の言語仕様について解説しました。