概要

本体提案「cgo without a C toolchain」（#81450）の実験的実装を進めるため、cgobindings という GOEXPERIMENT フラグを新設する手続き的な提案です。実際の機能追加ではなく、実験コードを本体ツールチェインに安全に取り込むための「入れ物」を用意するものです。

ステータス変更

** → likely_accept**
2026-09-23のProposal Review Meeting（@aclements, @cherrymui, @griesemer, @ianlancetaylor, @neild）にて「likely accept」と判定され、最終コメント募集期間（last call for comments）に入りました。GOEXPERIMENTは既定で無効なままであり、本体提案(#81450)が採否未定の間だけ隔離して開発を進める仕組みであるため、実質的にリスクの少ない手続き的判断として速やかに合意形成されたものと考えられます。

技術的背景

現状の問題点

本体提案#81450は、C言語のコンパイラ・ツールチェインをインストールしなくても、事前ビルド済みのCライブラリ（.so/.a）にバインドするcgoパッケージをビルドできるようにする大掛かりな設計です。この種の大規模な変更を段階的に開発する際、実験段階のコードをいきなり通常ビルドパスに混ぜてしまうと、安定版ユーザーへの影響やレビューの複雑化を招くという課題があります。

提案された解決策

internal/goexperiment パッケージに cgobindings という新しいGOEXPERIMENTを追加します。これにより、開発チームは提案中の機能（Goの構文でC宣言を表現する「バインディングファイル」の生成・解釈、Cグルーコードの代わりにGo/アセンブリで生成する仕組みなど）を、このフラグの内側に隔離して段階的に実装できます。本体提案が正式に受理されれば、GOEXPERIMENTは削除され機能が標準で有効化されます。逆に却下された場合は、フラグ配下のコードごと全て削除されます。

これによって何ができるようになるか

このproposal自体は一般の開発者向けAPIではなく、Goチーム内部の開発プロセスを整えるものです。実現すると次のような利点があります。

1. Goチームが cgo コマンドや cmd/go に対する実験的な変更を、mainブランチに安全にマージしながら継続的に開発できる。
2. 興味のある外部開発者が GOEXPERIMENT=cgobindings を設定してGoをソースからビルドすることで、早期に機能を試し、フィードバックを本体提案#81450の議論にフィードバックできる。
3. 本体提案の設計(バインディングファイルの形式、union型の扱い、ランタイムcgoの扱いなど、まだ議論が続いている論点)を、実際に動くコードを見ながら検証できる。

コード例

// Before: GOEXPERIMENTフラグが存在しないため、
// cgoバインディングの実験的コードは通常ビルドに混在させるか、
// フォークやブランチで別途管理する必要がある
// After: 実験フラグを有効にしてソースからGoをビルド
// $ GOEXPERIMENT=cgobindings ./make.bash
//
// 有効化すると、cmd/cgo や cmd/go 内で
// //cgo:binding アノテーションを使ったバインディングファイルの
// 生成・解釈といった実験的パスが利用可能になる

議論のハイライト

• 本Issueは技術設計そのものではなく、開発プロセス上の合意（GOEXPERIMENTの新設）のみを求めるものであり、議論は非常に短く、大きな反対意見は出ていません。
• 実装CL（go.dev/cl/832864: internal/goexperiment: add cgobindings experiment）が既に提出されており、提案とほぼ同時に実装作業が進んでいたことが分かります。
• GOEXPERIMENTは「受理されれば削除して恒久化、却下されれば丸ごと削除」という明確な運用ルールが定められており、これが迅速な合意形成を後押ししたと考えられます。
• 本体提案#81450では、バインディングファイルの形式（//cgo:bindingアノテーション方式 vs 別ファイルのDSL方式）やunion型のABI表現、runtime/cgoパッケージの扱いなど、まだ活発な議論が続いており、cgobindingsフラグはこれらの論点を実装しながら検証するための土台と位置づけられます。