[インデックス 1052] ファイルの概要

このコミットは、Go言語の仕様書である doc/go_spec.txt に、パラメータの引き渡し、特に可変長引数（... パラメータ）の扱いに関するセクションを追加するものです。Go言語の初期段階において、可変長引数がどのように内部的に処理されるか、そして関数間でどのように引き渡されるかについての詳細な記述が加えられました。

コミット

コミットハッシュ: 69e26bf28d989d21e025fefc9ce091cee7953285
作者: Robert Griesemer gri@golang.org
コミット日時: 2008年11月4日火曜日 16:46:45 -0800

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/69e26bf28d989d21e025fefc9ce091cee7953285

元コミット内容

- added (incomplete) section on parameter passing
- decribe passing of "..." parameters for a start

R=r
DELTA=70  (69 added, 0 deleted, 1 changed)
OCL=18503
CL=18503

このコミットは、Go言語の仕様策定が進行中であった2008年という非常に初期の段階で行われました。Go言語は、その設計思想としてシンプルさと効率性を重視しており、関数における可変長引数のサポートもその一部です。しかし、可変長引数がどのようにメモリ上で表現され、関数呼び出しの際にどのように処理されるかという内部的なメカニズムは、言語の正確な動作を保証し、コンパイラやランタイムの実装者が参照するための重要な情報です。

このコミット以前の仕様書には、パラメータの引き渡しに関する詳細な記述が不足していたと考えられます。特に、可変長引数のような特殊なケースについては、その挙動が明確に定義されている必要がありました。この変更は、Go言語の仕様をより完全で厳密なものにするための、基礎的なステップの一つとして行われました。これにより、開発者は可変長引数の動作を正確に理解し、それを利用した堅牢なコードを記述できるようになります。また、コンパイラの実装者にとっても、可変長引数の処理方法に関する明確な指針が提供されることになります。

前提知識の解説

このコミットの技術的詳細を理解するためには、以下のGo言語の基本的な概念を把握しておく必要があります。

可変長引数（Variadic Parameters）: Go言語では、関数の最後のパラメータに ... を付けることで、その関数が任意の数の引数を受け取れるように定義できます。例えば、func sum(nums ...int) int のように定義された関数は、sum(1, 2, 3) や sum(10, 20) のように、int 型の引数をいくつでも受け取ることができます。関数内部では、可変長引数はスライスとして扱われます。
空インターフェース（Empty Interface: interface{}）: Go言語の interface{} は、メソッドを一つも持たないインターフェースです。Goの型システムにおいて、すべての型は interface{} を実装しているとみなされます。これは、任意の型の値を interface{} 型の変数に格納できることを意味します。これにより、異なる型の値を統一的に扱うことが可能になりますが、その値にアクセスするには型アサーションやリフレクションが必要になります。
リフレクション（Reflection）: リフレクションとは、プログラムの実行中に、その構造（型、フィールド、メソッドなど）を検査したり、操作したりする機能です。Go言語の reflect パッケージは、この機能を提供します。これにより、コンパイル時には不明な型や構造体のフィールドに動的にアクセスしたり、値を設定したりすることが可能になります。このコミットで記述されているように、可変長引数の内部構造にアクセスするためにはリフレクションが用いられます。
構造体（Struct）: 構造体は、異なる型のフィールドをまとめた複合データ型です。Go言語では、関連するデータを一つのまとまりとして扱うためによく使用されます。このコミットでは、可変長引数が内部的に匿名構造体としてラップされることが説明されており、その構造体のフィールドが実際の引数に対応します。

技術的詳細

このコミットで追加された「Parameter passing」セクションは、Go言語における可変長引数の内部的な処理メカニズムについて、非常に重要な洞察を提供しています。

主要なポイントは以下の通りです。

... パラメータの型: 関数内部では、... パラメータの型は「空インターフェース interface{}」であると記述されています。これは、可変長引数として渡される実際の値がどのような型であっても、interface{} 型として受け取られることを意味します。
動的な型と内部構造: interface{} 型として受け取られた ... パラメータの「動的な型（dynamic type）」、つまり実際に格納されている値の型は、擬似的な表記で以下のような構造体ポインタとして表現されます。
```
*struct {
    arg(0) typeof(arg(0));
    arg(1) typeof(arg(1));
    arg(2) typeof(arg(2));
    ...
    arg(n-1) typeof(arg(n-1));
}
```
これは、可変長引数として渡された個々の引数（arg(i)）が、それぞれ自身の型（typeof(arg(i))）を持つ構造体のフィールドとしてラップされることを示しています。そして、この構造体へのポインタが関数に渡されます。
引数のラッピング: 具体的な例として、func f(x int, s string, f_extra ...) という関数と、f(42, "foo", 3.14, true, &[]int{1, 2, 3}) という呼び出しが挙げられています。この場合、3.14、true、&[]int{1, 2, 3} といった可変長引数部分が、以下のような構造体にラップされます。
```
*struct {
    arg0 float;
    arg1 bool;
    arg2 *[3]int;
}
```
そして、この構造体へのポインタが f 関数に渡され、f 関数内では f_extra が interface{} 型としてこのポインタを保持します。リフレクションを使用することで、この構造体のフィールドにアクセスし、元の引数の値を取り出すことができます。
... パラメータの再引き渡しにおける特殊ケース: 非常に重要な特殊ケースとして、ある関数が受け取った ... パラメータを、別の関数の ... パラメータとしてそのまま引き渡す場合が記述されています。例えば、関数 f が f_extra ... を受け取り、それを func g(x int, g_extra ...) という関数 g に g(x, f_extra); のように渡す場合です。この場合、f_extra は再度構造体にラップされることはなく、g 関数にそのまま引き渡されます。つまり、g 関数内の g_extra に格納される実際の値は、f 関数内の f_extra に格納されていた値と全く同じになります。これは、不必要なラッピングとアンラッピングのオーバーヘッドを避けるための最適化であり、効率的な可変長引数の連鎖的な引き渡しを可能にします。

これらの技術的詳細は、Go言語のコンパイラが可変長引数をどのように処理し、ランタイムがどのようにメモリを管理するかについての基盤を形成しています。また、Go言語のリフレクション機能が、このような動的な型情報へのアクセスを可能にしていることも示唆しています。

コアとなるコードの変更箇所

変更は doc/go_spec.txt ファイルに対して行われました。

日付の更新:

--- a/doc/go_spec.txt
+++ b/doc/go_spec.txt
@@ -4,7 +4,7 @@ The Go Programming Language Specification (DRAFT)
 Robert Griesemer, Rob Pike, Ken Thompson

 ----
-(November 3, 2008)
+(November 4, 2008)

仕様書の日付が2008年11月3日から11月4日に更新されました。

目次への追加:
```
@@ -168,6 +172,7 @@ Contents
 		Slices
 		Type guards
 		Calls
+			Parameter passing
```
「Contents」（目次）の「Calls」セクションの下に「Parameter passing」という新しいサブセクションが追加されました。

「Parameter passing」セクションの追加:

@@ -1761,6 +1766,70 @@ However, a function declared this way is not a method.\n There is no distinct method type and there are no method literals.\n \n \n+Parameter passing\n+----\n+\n+TODO expand this section (right now only "..." parameters are covered).\n+\n+Inside a function, the type of the "..." parameter is the empty interface\n+"interface {}". The dynamic type of the parameter - that is, the type of\n+the actual value stored in the parameter - is of the form (in pseudo-\n+notation)\n+\n+\t*struct {\n+\t\targ(0) typeof(arg(0));\n+\t\targ(1) typeof(arg(1));\t\n+\t\targ(2) typeof(arg(2));\n+\t\t...\n+\t\targ(n-1) typeof(arg(n-1));\n+\t}\n+\n+where the "arg(i)"'s correspond to the actual arguments passed in place\n+of the "..." parameter (the parameter and type names are for illustration\n+only). Reflection code may be used to access the struct value and its fields.\n+Thus, arguments provided in place of a "..." parameter are wrapped into\n+a corresponding struct, and a pointer to the struct is passed to the\n+function instead of the actual arguments.\n+\n+For instance, given the function\n+\n+\tfunc f(x int, s string, f_extra ...)\n+\n+and the call\n+\n+\tf(42, "foo", 3.14, true, &[]int{1, 2, 3})\n+\n+Upon invocation, the parameters "3.14", "true", and "*[3]int{1, 2, 3}"\n+are wrapped into a struct and the pointer to the struct is passed to f.\n+In f the type of parameter "f_extra" is "interface{}".\n+The dynamic type of "f_extra" is the type of the actual value assigned\n+to it upon invocation (the field names "arg0", "arg1", "arg2" are made\n+up for illustration only, they are not accessible via reflection):\n+\n+\t*struct {\n+\t\targ0 float;\n+\t\targ1 bool;\n+\t\targ2 *[3]int;\n+\t}\n+\n+The values of the fields "arg0", "arg1", and "arg2" are "3.14", "true",\n+and "*[3]int{1, 2, 3}".\n+\n+As a special case, if a function passes a "..." parameter as the argument\n+for a "..." parameter of a function, the parameter is not wrapped again into\n+a struct. Instead it is passed along unchanged. For instance, the function\n+f may call a function g with declaration\n+\n+\tfunc g(x int, g_extra ...)\n+\n+as\n+\n+\tg(x, f_extra);\n+\n+Inside g, the actual value stored in g_extra is the same as the value stored\n+in f_extra.\n+\n+\n Operators\n ----\n ```
このセクションが新規に追加され、可変長引数の内部的な挙動が詳細に記述されています。

コアとなるコードの解説

追加された Parameter passing セクションは、Go言語の可変長引数（... パラメータ）の動作を、実装レベルに近い形で説明しています。

interface{} 型としての扱い: 関数内で ... パラメータは interface{} 型として扱われることが明記されています。これは、Goの型システムにおけるポリモーフィズムの強力な例であり、異なる型の引数を単一のメカニズムで処理できることを示しています。
内部的な構造体ラッピング: 最も重要な点は、可変長引数として渡された複数の値が、実行時に「匿名構造体」としてラップされ、その構造体へのポインタが関数に渡されるというメカニズムです。擬似コードで示された *struct { arg(0) typeof(arg(0)); ... } は、このラッピングの概念を視覚的に表現しています。これにより、可変長引数の各要素が、それぞれ元の型を保持したまま、単一のエンティティとして関数に渡されることが保証されます。
リフレクションによるアクセス: この構造体のフィールドには、リフレクションコード（reflect パッケージ）を使用してアクセスできると述べられています。これは、コンパイル時には具体的な型が不明な可変長引数の要素に、実行時に動的にアクセスし、その値や型を検査・操作できることを意味します。
具体的な例: f(42, "foo", 3.14, true, &[]int{1, 2, 3}) の例は、異なる型の引数（float、bool、*[3]int）がどのように一つの構造体にまとめられるかを具体的に示しています。これにより、抽象的な概念がより理解しやすくなっています。
... パラメータの再引き渡しにおける最適化: g(x, f_extra); の例で示されているように、ある関数が受け取った ... パラメータを、別の関数の ... パラメータとしてそのまま渡す場合、不必要な再ラッピングが行われないという最適化が説明されています。これは、パフォーマンスの観点から非常に重要であり、Go言語が効率性を重視していることの表れです。この最適化により、可変長引数を扱う関数が連鎖的に呼び出される場合でも、余分なメモリ割り当てやコピーが発生せず、効率的な実行が保証されます。

このセクションは、Go言語の可変長引数が単なるシンタックスシュガーではなく、明確に定義された内部的なメカニズムに基づいて動作していることを示しており、言語設計の堅牢性を裏付けています。

参考にした情報源リンク

GitHub: golang/go commit 69e26bf28d989d21e025fefc9ce091cee7953285 https://github.com/golang/go/commit/69e26bf28d989d21e025fefc9ce091cee7953285
Go言語の公式ドキュメントおよび仕様書（現在のバージョンを参照し、当時の仕様との比較検討に利用）
Go言語の可変長引数、インターフェース、リフレクションに関する一般的な知識（Web検索を通じて得られた情報）

comemo