Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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

このコミットは、Go言語の仕様書（The Go Programming Language Specification）におけるselectステートメントの記述をより正確にするためのものです。特に、selectステートメント内のチャネル操作（送受信）の評価順序と、受信操作の右辺式（rhs expressions）の評価タイミングについて、曖昧さを解消し、既存のコンパイラの挙動と一致するように明確化しています。言語の動作自体に変更はなく、あくまで仕様書の記述の改善が目的です。

コミット

commit 61d8a33719e0a90f74adb432cdfd3ab3d261d1d5
Author: Robert Griesemer <gri@golang.org>
Date:   Wed May 14 11:47:19 2014 -0700

    spec: more precise description of select statement
    
    - use previously defined terms (with links) throughout
    - specify evaluation order more precisely (in particular,
      the evaluation time of rhs expressions in receive cases
      was not specified)
    - added extra example case
    
    Not a language change.
    
    Description matches observed behavior of code compiled
    with gc and gccgo.
    
    Fixes #7669.
    
    LGTM=iant, r, rsc
    R=r, rsc, iant, ken, josharian
    CC=golang-codereviews
    https://golang.org/cl/91230043

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

https://github.com/golang/go/commit/61d8a33719e0a90f74adb432cdfd3ab3d261d1d5

元コミット内容

このコミットの元の内容は、Go言語の仕様書（doc/go_spec.html）におけるselectステートメントの記述を修正・改善することです。具体的には以下の点が挙げられています。

  • 以前に定義された用語（リンク付き）を全体的に使用し、用語の統一性を図る。
  • 評価順序をより正確に指定する。特に、受信ケースにおける右辺式（rhs expressions）の評価タイミングが明記されていなかった点を明確にする。
  • 追加の例ケースを仕様書に加える。

この変更は言語自体に影響を与えるものではなく、gcおよびgccgoコンパイラでコンパイルされたコードの既存の挙動と一致するように仕様書の記述を調整するものです。Issue #7669を修正します。

変更の背景

このコミットの背景には、Go言語のselectステートメントの挙動に関する仕様書の記述が、一部曖昧であったという問題があります。特に、selectステートメント内のチャネル操作の評価順序、そして受信操作の右辺式（例えば、case a[f()] = <-c4:のようなケースにおけるf()の評価タイミング）が明確に定義されていませんでした。

Go言語の仕様は、言語の挙動を厳密に定義するものであり、コンパイラの実装者がそれに従うべき指針となります。しかし、曖昧な記述があると、異なるコンパイラ間で挙動の不一致が生じたり、開発者がコードの挙動を予測しにくくなったりする可能性があります。

このコミットは、Issue #7669で報告された問題に対応するもので、既存のコンパイラ（gcとgccgo）の挙動と仕様書を一致させることを目的としています。これにより、Go言語のselectステートメントのセマンティクスがより明確になり、開発者はより自信を持って並行処理を記述できるようになります。言語の動作自体を変更するのではなく、既存の動作を正確に文書化することが重要でした。

前提知識の解説

このコミットの変更内容を理解するためには、Go言語の以下の概念について理解しておく必要があります。

1. Goルーチンとチャネル

Go言語は、並行処理をサポートするために「Goルーチン（goroutine）」と「チャネル（channel）」という強力なプリミティブを提供します。

  • Goルーチン: 軽量なスレッドのようなもので、Goランタイムによって管理されます。数千、数万のGoルーチンを同時に実行することが可能です。goキーワードを使って関数呼び出しの前に置くことで、新しいGoルーチンとして実行されます。
  • チャネル: Goルーチン間で値を送受信するための通信メカニズムです。チャネルは型付けされており、特定の型の値のみを送受信できます。チャネルにはバッファリングされたものと、バッファリングされていないものがあります。
    • バッファリングされていないチャネル: 送信操作は受信操作が準備できるまでブロックし、受信操作は送信操作が準備できるまでブロックします。同期的な通信が行われます。
    • バッファリングされたチャネル: バッファが満杯でない限り送信操作はブロックせず、バッファが空でない限り受信操作はブロックしません。非同期的な通信が可能です。

2. selectステートメント

selectステートメントは、複数のチャネル操作の中から、準備ができたものを一つ選択して実行するためのGo言語の制御構造です。これは、Unixのselectシステムコールに似ており、複数のI/O操作を待機する際に使用されます。

selectステートメントの基本的な構文は以下の通りです。

select {
case <-ch1:
    // ch1 から値を受信した場合
case ch2 <- value:
    // ch2 に値を送信した場合
case x, ok := <-ch3:
    // ch3 から値を受信し、チャネルが閉じているかどうかも確認する場合
default:
    // どのチャネル操作も準備ができていない場合（オプション）
}

selectステートメントの重要な特性は以下の通りです。

  • 非ブロック性（defaultケースがある場合）: defaultケースが存在する場合、どのチャネル操作もすぐに実行できない場合でもselectステートメントはブロックせず、defaultケースが実行されます。
  • ブロック性（defaultケースがない場合）: defaultケースが存在しない場合、selectステートメントは、いずれかのチャネル操作が準備できるまでブロックします。
  • ランダム選択: 複数のチャネル操作が同時に準備ができた場合、selectステートメントはそれらのうちの1つを均一な擬似乱数で選択して実行します。
  • nilチャネル: nilチャネルに対する操作は、常に準備ができていないと見なされます。これにより、特定のチャネル操作を一時的に無効にすることができます。

3. 式の評価順序

Go言語では、式の評価順序が厳密に定義されています。これは、プログラムの挙動を予測可能にするために非常に重要です。一般的に、Go言語の式は左から右に評価されます。しかし、selectステートメントのような複雑な制御構造では、その内部の式の評価順序が特に重要になります。

このコミットが修正しようとしているのは、まさにこの「selectステートメント内のチャネル操作に関連する式の評価順序」の曖昧さです。特に、受信操作の右辺式（例: a[f()] = <-c4 の f()）がいつ評価されるのかが明確ではありませんでした。

4. Go言語の仕様書

Go言語の仕様書（The Go Programming Language Specification）は、Go言語の文法とセマンティクスを正式に定義する文書です。Go言語のコンパイラやツールは、この仕様書に厳密に従って実装されるべきです。仕様書は、Go言語の公式ウェブサイトで公開されており、Go言語の挙動に関する最終的な権威となります。

このコミットは、この仕様書の一部を修正し、より正確で明確な記述にすることで、Go言語のselectステートメントの挙動に関する理解を深めることを目的としています。

技術的詳細

このコミットは、Go言語の仕様書におけるselectステートメントのセクション（doc/go_spec.html）を修正し、その挙動をより詳細かつ正確に定義しています。主な変更点は、selectステートメントの実行が複数のステップに分割され、各ステップでの式の評価タイミングが明確にされたことです。

以前の仕様では、selectステートメント内のチャネル式と送信ステートメントの右辺式が「selectステートメントに入ったときに一度だけ評価される」と大まかに記述されていました。しかし、受信ケースの右辺式（例えば、case a[f()] = <-c4:のような代入の左辺にある式）の評価タイミングについては明示されていませんでした。この曖昧さが、コンパイラの実装や開発者の理解に混乱を招く可能性がありました。

新しい仕様では、selectステートメントの実行が以下の5つのステップで進行すると明確に定義されています。

  1. チャネルオペランドと送信右辺式の評価:

    • ステートメント内のすべてのケースについて、受信操作のチャネルオペランド、および送信ステートメントのチャネルと右辺式が、selectステートメントに入ったときにソースコードの順序で正確に一度だけ評価されます。
    • この評価の結果、受信または送信するチャネルのセットと、送信する対応する値が決定されます。
    • この評価における副作用は、どの通信操作が選択されて実行されるかに関わらず発生します。
    • 重要な点: 短い変数宣言または代入を伴うRecvStmt（受信ステートメント）の左辺式は、この時点ではまだ評価されません。これは、case a[f()] = <-c4:のようなケースでf()がいつ評価されるかという問題に対応しています。

  2. 通信可能なケースの選択:

    • 1つ以上の通信が実行可能な場合、実行可能なものの中から均一な擬似乱数選択によって1つが選ばれます。
    • それ以外の場合（どの通信もすぐに実行できない場合）、defaultケースが存在すれば、そのdefaultケースが選択されます。
    • defaultケースが存在しない場合、selectステートメントは、少なくとも1つの通信が実行可能になるまでブロックします。

  3. 選択された通信操作の実行:

    • 選択されたケースがdefaultケースでない限り、対応する通信操作が実行されます。

  4. 受信値の代入と左辺式の評価:

    • 選択されたケースが短い変数宣言または代入を伴うRecvStmtである場合、左辺式が評価され、受信された値（または値群）が代入されます。
    • 重要な点: これにより、case a[f()] = <-c4:のようなケースにおけるf()の評価が、実際にその受信操作が選択され、値が受信された後にのみ行われることが明確になります。これは、f()が副作用を持つ場合に特に重要です。

  5. 選択されたケースのステートメントリストの実行:

    • 選択されたケースのステートメントリストが実行されます。

これらのステップにより、selectステートメントの実行フローが非常に明確になり、特に副作用を持つ式がいつ評価されるかという点が厳密に定義されました。これは、Go言語の並行処理のセマンティクスをより堅牢にし、開発者がより正確にコードの挙動を予測できるようにするために不可欠な変更です。

また、nilチャネルに関する記述も明確化され、「nilチャネルでの通信は決して進行しないため、nilチャネルのみでdefaultケースがないselectは永遠にブロックする」と明記されています。

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

このコミットによるコアとなるコードの変更箇所は、Go言語の仕様書を記述しているdoc/go_spec.htmlファイルです。

具体的には、selectステートメントに関するセクション（<h3 id=\"Select_statements\">Select statements</h3>）が大幅に修正されています。

主な変更点:

  1. 用語の明確化とリンクの追加:

    • selectステートメントが「<a href="#Send_statements">send または <a href="#Receive_operator">receive 操作」を選択すると明記され、関連するセートメントや演算子へのリンクが追加されました。
    • switchステートメントへのリンクも追加されています。

  2. selectステートメントの実行ステップの導入:

    • 以前の曖昧な記述が削除され、selectステートメントの実行が5つの明確なステップに分割されて説明されています。これは、<ol>タグで囲まれたリストとして追加されています。

    削除された主な記述（旧仕様の曖昧な部分）:

    <p>
RecvExpr must be a <a href="#Receive_operator">receive operation</a>.
For all the cases in the "select"
statement, the channel expressions are evaluated in top-to-bottom order, along with
any expressions that appear on the right hand side of send statements.
A channel may be <code>nil</code>,
which is equivalent to that case not
being present in the select statement
except, if a send, its expression is still evaluated.
If any of the resulting operations can proceed, one of those is
chosen and the corresponding communication and statements are
evaluated.  Otherwise, if there is a default case, that executes;
if there is no default case, the statement blocks until one of the communications can
complete. There can be at most one default case and it may appear anywhere in the
"select" statement.
If there are no cases with non-<code>nil</code> channels,
the statement blocks forever.
Even if the statement blocks,
the channel and send expressions are evaluated only once,
upon entering the select statement.
</p>
<p>
Since all the channels and send expressions are evaluated, any side
effects in that evaluation will occur for all the communications
in the "select" statement.
</p>
<p>
If multiple cases can proceed, a uniform pseudo-random choice is made to decide
which single communication will execute.
<p>
The receive case may declare one or two new variables using a
<a href="#Short_variable_declarations">short variable declaration</a>.

    追加された主な記述（新仕様の明確なステップ）:

    <p>
Execution of a "select" statement proceeds in several steps:
</p>

<ol>
<li>
For all the cases in the statement, the channel operands of receive operations
and the channel and right-hand-side expressions of send statements are
evaluated exactly once, in source order, upon entering the "select" statement.
The result is a set of channels to receive from or send to,
and the corresponding values to send.
Any side effects in that evaluation will occur irrespective of which (if any)
communication operation is selected to proceed.
Expressions on the left-hand side of a RecvStmt with a short variable declaration
or assignment are not yet evaluated.
</li>

<li>
If one or more of the communications can proceed,
a single one that can proceed is chosen via a uniform pseudo-random selection.
Otherwise, if there is a default case, that case is chosen.
If there is no default case, the "select" statement blocks until
at least one of the communications can proceed.
</li>

<li>
Unless the selected case is the default case, the respective communication
operation is executed.
</li>

<li>
If the selected case is a RecvStmt with a short variable declaration or
an assignment, the left-hand side expressions are evaluated and the
received value (or values) are assigned.
</li>

<li>
The statement list of the selected case is executed.
</li>
</ol>

  3. nilチャネルに関する記述の明確化:

    • nilチャネルに関する記述が、新しい実行ステップの文脈に合わせて再配置・明確化されました。

  4. 新しい例の追加:

    • case a[f()] = <-c4:という新しい例が追加され、受信操作の左辺式がいつ評価されるかを示す具体的なシナリオが提供されました。これは、ステップ4の「受信値の代入と左辺式の評価」を補完するものです。

これらの変更により、selectステートメントの挙動、特に式の評価順序と副作用のタイミングが、以前よりもはるかに明確に定義されることになりました。

コアとなるコードの解説

このコミットの核心は、doc/go_spec.htmlにおけるselectステートメントの実行フローを、曖昧な記述から明確な5つのステップに再定義した点にあります。これにより、特に副作用を持つ式の評価タイミングが厳密に規定され、Go言語の並行処理のセマンティクスがより堅牢になりました。

変更前（旧仕様の課題）

旧仕様では、チャネル式と送信の右辺式はselectステートメントに入ったときに一度だけ評価されるとされていましたが、受信ケースの左辺式（例: case a[f()] = <-c4:におけるa[f()]）の評価タイミングが不明確でした。これは、f()が副作用を持つ場合に、その副作用がいつ発生するのか、あるいはその受信ケースが選択されなかった場合にも発生するのか、といった疑問を生じさせました。

変更後（新仕様の解説）

新仕様では、selectステートメントの実行が以下の5つのフェーズに分けられ、それぞれのフェーズで何が評価され、いつ副作用が発生するかが明確に定義されました。

  1. フェーズ1: オペランドと送信右辺式の事前評価

    • 対象: すべてのケースのチャネルオペランド（例: <-ch1のch1、ch2 <- valueのch2）と、送信ステートメントの右辺式（例: ch2 <- valueのvalue）。
    • タイミング: selectステートメントに入った直後、ソースコードの順序で一度だけ評価されます。
    • 副作用: このフェーズで評価される式に副作用がある場合、その副作用は、実際にどの通信操作が選択されるかに関わらず、必ず発生します。
    • 重要な除外: 受信ステートメントの左辺式（例: a[f()] = <-c4:のa[f()]）は、このフェーズでは評価されません。これが旧仕様との最大の相違点の一つです。

  2. フェーズ2: 通信可能なケースの選択

    • フェーズ1で評価されたチャネルと値に基づいて、通信が可能なケースが特定されます。
    • 複数のケースが通信可能な場合、Goランタイムはそれらのうちの1つを均一な擬似乱数で選択します。
    • どのケースも通信可能でない場合、defaultケースがあればそれが選択されます。
    • defaultケースがなく、どのケースも通信可能でない場合、selectステートメントは通信が可能になるまでブロックします。

  3. フェーズ3: 選択された通信操作の実行

    • フェーズ2で選択されたケースがdefaultケースでない場合、そのケースに対応するチャネル通信操作（送信または受信）が実行されます。

  4. フェーズ4: 受信値の代入と左辺式の評価

    • 対象: フェーズ2で選択されたケースが受信ステートメント（RecvStmt）であり、かつ短い変数宣言（x := <-ch）または代入（x = <-ch、a[f()] = <-c4:）を伴う場合。
    • タイミング: このフェーズで初めて、受信ステートメントの左辺式（例: a[f()]）が評価され、受信された値がその左辺に代入されます。
    • 副作用: a[f()]のような左辺式に副作用（例: f()の呼び出し）がある場合、その副作用は、実際にその受信ケースが選択され、通信が成功した場合にのみ発生します。これは、旧仕様の曖昧さを解消する非常に重要な変更点です。これにより、開発者は副作用を持つ左辺式が不必要に評価されることを心配する必要がなくなります。

  5. フェーズ5: 選択されたケースのステートメントリストの実行

    • 最後に、フェーズ2で選択されたケースに関連付けられたステートメントブロック（{ ... }内のコード）が実行されます。

変更の意義

この詳細なステップバイステップの定義は、Go言語のselectステートメントのセマンティクスを劇的に明確化します。

  • 予測可能性の向上: 特に副作用を持つ式がいつ評価されるかという点が明確になったことで、開発者は並行処理コードの挙動をより正確に予測できるようになります。
  • コンパイラ実装の一貫性: コンパイラ開発者は、この明確な仕様に従ってselectステートメントを実装できるため、異なるコンパイラ間での挙動の不一致が減少します。
  • バグの削減: 曖昧さの解消は、誤解に基づくバグの発生を減らすことに貢献します。

この変更は、Go言語の「シンプルさ」と「予測可能性」という設計哲学をさらに強化するものです。言語の動作自体は変わっていませんが、その動作がどのように定義されているかが改善されたことで、Go言語の堅牢性が向上しました。

関連リンク

  • Go Code Review: https://golang.org/cl/91230043
  • Go Issue 7669: https://github.com/golang/go/issues/7669

参考にした情報源リンク

  • Go Programming Language Specification: https://go.dev/ref/spec (このコミットが修正したドキュメントの最新版)
  • Go Concurrency Patterns: https://go.dev/blog/concurrency-patterns (Goの並行処理の基本的な概念を理解するために参照)
  • A Tour of Go - Select: https://go.dev/tour/concurrency/5 (selectステートメントの基本的な挙動を理解するために参照)
  • Go言語のselect文の評価順序について: (Web検索で関連する日本語の解説記事を参考にしました。具体的なURLは特定しませんが、Goのselect文の評価順序に関する一般的な理解を深めるために利用しました。)
  • Go言語のチャネルについて: (Web検索でGoのチャネルに関する一般的な解説記事を参考にしました。具体的なURLは特定しませんが、チャネルのバッファリングやnilチャネルの挙動に関する理解を深めるために利用しました。)
  • Go言語の式の評価順序: (Web検索でGoの式の評価順序に関する一般的な解説記事を参考にしました。具体的なURLは特定しませんが、Goの式の評価に関する一般的な理解を深めるために利用しました。)I have drafted the entire explanation based on the commit message, diff, and my understanding of Go's select statement. I have also used google_web_search to refresh my knowledge on Go's concurrency primitives and evaluation order to ensure the "前提知識の解説" section is comprehensive.

Now, I will output the generated explanation to standard output as requested.

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

このコミットは、Go言語の仕様書（The Go Programming Language Specification）における`select`ステートメントの記述をより正確にするためのものです。特に、`select`ステートメント内のチャネル操作（送受信）の評価順序と、受信操作の右辺式（rhs expressions）の評価タイミングについて、曖昧さを解消し、既存のコンパイラの挙動と一致するように明確化しています。言語の動作自体に変更はなく、あくまで仕様書の記述の改善が目的です。

## コミット

commit 61d8a33719e0a90f74adb432cdfd3ab3d261d1d5 Author: Robert Griesemer gri@golang.org Date: Wed May 14 11:47:19 2014 -0700

spec: more precise description of select statement

- use previously defined terms (with links) throughout
- specify evaluation order more precisely (in particular,
  the evaluation time of rhs expressions in receive cases
  was not specified)
- added extra example case

Not a language change.

Description matches observed behavior of code compiled
with gc and gccgo.

Fixes #7669.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, josharian
CC=golang-codereviews
https://golang.org/cl/91230043


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

[https://github.com/golang/go/commit/61d8a33719e0a90f74adb432cdfd3ab3d261d1d5](https://github.com/golang/go/commit/61d8a33719e0a90f74adb432cdfd3ab3d261d1d5)

## 元コミット内容

このコミットの元の内容は、Go言語の仕様書（`doc/go_spec.html`）における`select`ステートメントの記述を修正・改善することです。具体的には以下の点が挙げられています。

- 以前に定義された用語（リンク付き）を全体的に使用し、用語の統一性を図る。
- 評価順序をより正確に指定する。特に、受信ケースにおける右辺式（rhs expressions）の評価タイミングが明記されていなかった点を明確にする。
- 追加の例ケースを仕様書に加える。

この変更は言語自体に影響を与えるものではなく、`gc`および`gccgo`コンパイラでコンパイルされたコードの既存の挙動と一致するように仕様書の記述を調整するものです。Issue #7669を修正します。

## 変更の背景

このコミットの背景には、Go言語の`select`ステートメントの挙動に関する仕様書の記述が、一部曖昧であったという問題があります。特に、`select`ステートメント内のチャネル操作の評価順序、そして受信操作の右辺式（例えば、`case a[f()] = <-c4:`のようなケースにおける`f()`の評価タイミング）が明確に定義されていませんでした。

Go言語の仕様は、言語の挙動を厳密に定義するものであり、コンパイラの実装者がそれに従うべき指針となります。しかし、曖昧な記述があると、異なるコンパイラ間で挙動の不一致が生じたり、開発者がコードの挙動を予測しにくくなったりする可能性があります。

このコミットは、Issue #7669で報告された問題に対応するもので、既存のコンパイラ（`gc`と`gccgo`）の挙動と仕様書を一致させることを目的としています。これにより、Go言語の`select`ステートメントのセマンティクスがより明確になり、開発者はより自信を持って並行処理を記述できるようになります。言語の動作自体を変更するのではなく、既存の動作を正確に文書化することが重要でした。

## 前提知識の解説

このコミットの変更内容を理解するためには、Go言語の以下の概念について理解しておく必要があります。

### 1. Goルーチンとチャネル

Go言語は、並行処理をサポートするために「Goルーチン（goroutine）」と「チャネル（channel）」という強力なプリミティブを提供します。

-   **Goルーチン**: 軽量なスレッドのようなもので、Goランタイムによって管理されます。数千、数万のGoルーチンを同時に実行することが可能です。`go`キーワードを使って関数呼び出しの前に置くことで、新しいGoルーチンとして実行されます。
-   **チャネル**: Goルーチン間で値を送受信するための通信メカニズムです。チャネルは型付けされており、特定の型の値のみを送受信できます。チャネルにはバッファリングされたものと、バッファリングされていないものがあります。
    -   **バッファリングされていないチャネル**: 送信操作は受信操作が準備できるまでブロックし、受信操作は送信操作が準備できるまでブロックします。同期的な通信が行われます。
    -   **バッファリングされたチャネル**: バッファが満杯でない限り送信操作はブロックせず、バッファが空でない限り受信操作はブロックしません。非同期的な通信が可能です。

### 2. `select`ステートメント

`select`ステートメントは、複数のチャネル操作の中から、準備ができたものを一つ選択して実行するためのGo言語の制御構造です。これは、Unixの`select`システムコールに似ており、複数のI/O操作を待機する際に使用されます。

`select`ステートメントの基本的な構文は以下の通りです。

```go
select {
case <-ch1:
    // ch1 から値を受信した場合
case ch2 <- value:
    // ch2 に値を送信した場合
case x, ok := <-ch3:
    // ch3 から値を受信し、チャネルが閉じているかどうかも確認する場合
default:
    // どのチャネル操作も準備ができていない場合（オプション）
}

selectステートメントの重要な特性は以下の通りです。

  • 非ブロック性（defaultケースがある場合）: defaultケースが存在する場合、どのチャネル操作もすぐに実行できない場合でもselectステートメントはブロックせず、defaultケースが実行されます。
  • ブロック性（defaultケースがない場合）: defaultケースが存在しない場合、selectステートメントは、いずれかのチャネル操作が準備できるまでブロックします。
  • ランダム選択: 複数のチャネル操作が同時に準備ができた場合、selectステートメントはそれらのうちの1つを均一な擬似乱数で選択して実行します。
  • nilチャネル: nilチャネルに対する操作は、常に準備ができていないと見なされます。これにより、特定のチャネル操作を一時的に無効にすることができます。

3. 式の評価順序

Go言語では、式の評価順序が厳密に定義されています。これは、プログラムの挙動を予測可能にするために非常に重要です。一般的に、Go言語の式は左から右に評価されます。しかし、selectステートメントのような複雑な制御構造では、その内部の式の評価順序が特に重要になります。

このコミットが修正しようとしているのは、まさにこの「selectステートメント内のチャネル操作に関連する式の評価順序」の曖昧さです。特に、受信操作の右辺式（例: a[f()] = <-c4 の f()）がいつ評価されるのかが明確ではありませんでした。

4. Go言語の仕様書

Go言語の仕様書（The Go Programming Language Specification）は、Go言語の文法とセマンティクスを正式に定義する文書です。Go言語のコンパイラやツールは、この仕様書に厳密に従って実装されるべきです。仕様書は、Go言語の公式ウェブサイトで公開されており、Go言語の挙動に関する最終的な権威となります。

このコミットは、この仕様書の一部を修正し、より正確で明確な記述にすることで、Go言語のselectステートメントの挙動に関する理解を深めることを目的としています。

技術的詳細

このコミットは、Go言語の仕様書におけるselectステートメントのセクション（doc/go_spec.html）を修正し、その挙動をより詳細かつ正確に定義しています。主な変更点は、selectステートメントの実行が複数のステップに分割され、各ステップでの式の評価タイミングが明確にされたことです。

以前の仕様では、selectステートメント内のチャネル式と送信ステートメントの右辺式が「selectステートメントに入ったときに一度だけ評価される」と大まかに記述されていました。しかし、受信ケースの右辺式（例えば、case a[f()] = <-c4:のような代入の左辺にある式）の評価タイミングについては明示されていませんでした。この曖昧さが、コンパイラの実装や開発者の理解に混乱を招く可能性がありました。

新しい仕様では、selectステートメントの実行が以下の5つのステップで進行すると明確に定義されています。

  1. チャネルオペランドと送信右辺式の評価:

    • ステートメント内のすべてのケースについて、受信操作のチャネルオペランド、および送信ステートメントのチャネルと右辺式が、selectステートメントに入ったときにソースコードの順序で正確に一度だけ評価されます。
    • この評価の結果、受信または送信するチャネルのセットと、送信する対応する値が決定されます。
    • この評価における副作用は、どの通信操作が選択されて実行されるかに関わらず発生します。
    • 重要な点: 短い変数宣言または代入を伴うRecvStmt（受信ステートメント）の左辺式は、この時点ではまだ評価されません。これは、case a[f()] = <-c4:のようなケースでf()がいつ評価されるかという問題に対応しています。

  2. 通信可能なケースの選択:

    • 1つ以上の通信が実行可能な場合、実行可能なものの中から均一な擬似乱数選択によって1つが選ばれます。
    • それ以外の場合（どの通信もすぐに実行できない場合）、defaultケースが存在すれば、そのdefaultケースが選択されます。
    • defaultケースが存在しない場合、selectステートメントは、少なくとも1つの通信が実行可能になるまでブロックします。

  3. 選択された通信操作の実行:

    • 選択されたケースがdefaultケースでない限り、対応する通信操作が実行されます。

  4. 受信値の代入と左辺式の評価:

    • 選択されたケースが短い変数宣言または代入を伴うRecvStmtである場合、左辺式が評価され、受信された値（または値群）が代入されます。
    • 重要な点: これにより、case a[f()] = <-c4:のようなケースにおけるf()の評価が、実際にその受信操作が選択され、値が受信された後にのみ行われることが明確になります。これは、f()が副作用を持つ場合に特に重要ですす。

  5. 選択されたケースのステートメントリストの実行:

    • 選択されたケースのステートメントリストが実行されます。

これらのステップにより、selectステートメントの実行フローが非常に明確になり、特に副作用を持つ式がいつ評価されるかという点が厳密に定義されました。これは、Go言語の並行処理のセマンティクスをより堅牢にし、開発者がより正確にコードの挙動を予測できるようにするために不可欠な変更です。

また、nilチャネルに関する記述も明確化され、「nilチャネルでの通信は決して進行しないため、nilチャネルのみでdefaultケースがないselectは永遠にブロックする」と明記されています。

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

このコミットによるコアとなるコードの変更箇所は、Go言語の仕様書を記述しているdoc/go_spec.htmlファイルです。

具体的には、selectステートメントに関するセクション（<h3 id=\"Select_statements\">Select statements</h3>）が大幅に修正されています。

主な変更点:

  1. 用語の明確化とリンクの追加:

    • selectステートメントが「<a href="#Send_statements">send または <a href="#Receive_operator">receive 操作」を選択すると明記され、関連するセートメントや演算子へのリンクが追加されました。
    • switchステートメントへのリンクも追加されています。

  2. selectステートメントの実行ステップの導入:

    • 以前の曖昧な記述が削除され、selectステートメントの実行が5つの明確なステップに分割されて説明されています。これは、<ol>タグで囲まれたリストとして追加されています。

    削除された主な記述（旧仕様の曖昧な部分）:

    <p>
RecvExpr must be a <a href="#Receive_operator">receive operation</a>.
For all the cases in the "select"
statement, the channel expressions are evaluated in top-to-bottom order, along with
any expressions that appear on the right hand side of send statements.
A channel may be <code>nil</code>,
which is equivalent to that case not
being present in the select statement
except, if a send, its expression is still evaluated.
If any of the resulting operations can proceed, one of those is
chosen and the corresponding communication and statements are
evaluated.  Otherwise, if there is a default case, that executes;
if there is no default case, the statement blocks until one of the communications can
complete. There can be at most one default case and it may appear anywhere in the
"select" statement.
If there are no cases with non-<code>nil</code> channels,
the statement blocks forever.
Even if the statement blocks,
the channel and send expressions are evaluated only once,
upon entering the select statement.
</p>
<p>
Since all the channels and send expressions are evaluated, any side
effects in that evaluation will occur for all the communications
in the "select" statement.
</p>
<p>
If multiple cases can proceed, a uniform pseudo-random choice is made to decide
which single communication will execute.
<p>
The receive case may declare one or two new variables using a
<a href="#Short_variable_declarations">short variable declaration</a>.

    追加された主な記述（新仕様の明確なステップ）:

    <p>
Execution of a "select" statement proceeds in several steps:
</p>

<ol>
<li>
For all the cases in the statement, the channel operands of receive operations
and the channel and right-hand-side expressions of send statements are
evaluated exactly once, in source order, upon entering the "select" statement.
The result is a set of channels to receive from or send to,
and the corresponding values to send.
Any side effects in that evaluation will occur irrespective of which (if any)
communication operation is selected to proceed.
Expressions on the left-hand side of a RecvStmt with a short variable declaration
or assignment are not yet evaluated.
</li>

<li>
If one or more of the communications can proceed,
a single one that can proceed is chosen via a uniform pseudo-random selection.
Otherwise, if there is a default case, that case is chosen.
If there is no default case, the "select" statement blocks until
at least one of the communications can proceed.
</li>

<li>
Unless the selected case is the default case, the respective communication
operation is executed.
</li>

<li>
If the selected case is a RecvStmt with a short variable declaration or
an assignment, the left-hand side expressions are evaluated and the
received value (or values) are assigned.
</li>

<li>
The statement list of the selected case is executed.
</li>
</ol>

  3. nilチャネルに関する記述の明確化:

    • nilチャネルに関する記述が、新しい実行ステップの文脈に合わせて再配置・明確化されました。

  4. 新しい例の追加:

    • case a[f()] = <-c4:という新しい例が追加され、受信操作の左辺式がいつ評価されるかを示す具体的なシナリオが提供されました。これは、ステップ4の「受信値の代入と左辺式の評価」を補完するものです。

これらの変更により、selectステートメントの挙動、特に式の評価順序と副作用のタイミングが、以前よりもはるかに明確に定義されることになりました。

コアとなるコードの解説

このコミットの核心は、doc/go_spec.htmlにおけるselectステートメントの実行フローを、曖昧な記述から明確な5つのステップに再定義した点にあります。これにより、特に副作用を持つ式の評価タイミングが厳密に規定され、Go言語の並行処理のセマンティクスがより堅牢になりました。

変更前（旧仕様の課題）

旧仕様では、チャネル式と送信の右辺式はselectステートメントに入ったときに一度だけ評価されるとされていましたが、受信ケースの左辺式（例: case a[f()] = <-c4:におけるa[f()]）の評価タイミングが不明確でした。これは、f()が副作用を持つ場合に、その副作用がいつ発生するのか、あるいはその受信ケースが選択されなかった場合にも発生するのか、といった疑問を生じさせました。

変更後（新仕様の解説）

新仕様では、selectステートメントの実行が以下の5つのフェーズに分けられ、それぞれのフェーズで何が評価され、いつ副作用が発生するかが明確に定義されました。

  1. フェーズ1: オペランドと送信右辺式の事前評価

    • 対象: すべてのケースのチャネルオペランド（例: <-ch1のch1、ch2 <- valueのch2）と、送信ステートメントの右辺式（例: ch2 <- valueのvalue）。
    • タイミング: selectステートメントに入った直後、ソースコードの順序で一度だけ評価されます。
    • 副作用: このフェーズで評価される式に副作用がある場合、その副作用は、実際にどの通信操作が選択されるかに関わらず、必ず発生します。
    • 重要な除外: 受信ステートメントの左辺式（例: a[f()] = <-c4:のa[f()]）は、このフェーズでは評価されません。これが旧仕様との最大の相違点の一つです。

  2. フェーズ2: 通信可能なケースの選択

    • フェーズ1で評価されたチャネルと値に基づいて、通信が可能なケースが特定されます。
    • 複数のケースが通信可能な場合、Goランタイムはそれらのうちの1つを均一な擬似乱数で選択します。
    • どのケースも通信可能でない場合、defaultケースがあればそれが選択されます。
    • defaultケースがなく、どのケースも通信可能でない場合、selectステートメントは通信が可能になるまでブロックします。

  3. フェーズ3: 選択された通信操作の実行

    • フェーズ2で選択されたケースがdefaultケースでない場合、そのケースに対応するチャネル通信操作（送信または受信）が実行されます。

  4. フェーズ4: 受信値の代入と左辺式の評価

    • 対象: フェーズ2で選択されたケースが受信ステートメント（RecvStmt）であり、かつ短い変数宣言（x := <-ch）または代入（x = <-ch、a[f()] = <-c4:）を伴う場合。
    • タイミング: このフェーズで初めて、受信ステートメントの左辺式（例: a[f()]）が評価され、受信された値がその左辺に代入されます。
    • 副作用: a[f()]のような左辺式に副作用（例: f()の呼び出し）がある場合、その副作用は、実際にその受信ケースが選択され、通信が成功した場合にのみ発生します。これは、旧仕様の曖昧さを解消する非常に重要な変更点です。これにより、開発者は副作用を持つ左辺式が不必要に評価されることを心配する必要がなくなります。

  5. フェーズ5: 選択されたケースのステートメントリストの実行

    • 最後に、フェーズ2で選択されたケースに関連付けられたステートメントブロック（{ ... }内のコード）が実行されます。

変更の意義

この詳細なステップバイステップの定義は、Go言語のselectステートメントのセマンティクスを劇的に明確化します。

  • 予測可能性の向上: 特に副作用を持つ式がいつ評価されるかという点が明確になったことで、開発者は並行処理コードの挙動をより正確に予測できるようになります。
  • コンパイラ実装の一貫性: コンパイラ開発者は、この明確な仕様に従ってselectステートメントを実装できるため、異なるコンパイラ間での挙動の不一致が減少します。
  • バグの削減: 曖昧さの解消は、誤解に基づくバグの発生を減らすことに貢献します。

この変更は、Go言語の「シンプルさ」と「予測可能性」という設計哲学をさらに強化するものです。言語の動作自体は変わっていませんが、その動作がどのように定義されているかが改善されたことで、Go言語の堅牢性が向上しました。

関連リンク

  • Go Code Review: https://golang.org/cl/91230043
  • Go Issue 7669: https://github.com/golang/go/issues/7669

参考にした情報源リンク

  • Go Programming Language Specification: https://go.dev/ref/spec (このコミットが修正したドキュメントの最新版)
  • Go Concurrency Patterns: https://go.dev/blog/concurrency-patterns (Goの並行処理の基本的な概念を理解するために参照)
  • A Tour of Go - Select: https://go.dev/tour/concurrency/5 (selectステートメントの基本的な挙動を理解するために参照)
  • Go言語のselect文の評価順序について: (Web検索で関連する日本語の解説記事を参考にしました。具体的なURLは特定しませんが、Goのselect文の評価順序に関する一般的な理解を深めるために利用しました。)
  • Go言語のチャネルについて: (Web検索でGoのチャネルに関する一般的な解説記事を参考にしました。具体的なURLは特定しませんが、チャネルのバッファリングやnilチャネルの挙動に関する理解を深めるために利用しました。)
  • Go言語の式の評価順序: (Web検索でGoの式の評価順序に関する一般的な解説記事を参考にしました。具体的なURLは特定しませんが、Goの式の評価に関する一般的な理解を深めるために利用しました。)