概要

GODEBUG 設定（環境変数によるGo動作制御フラグ）の廃止・削除に関する公式ポリシーを制定するproposalです。増え続ける GODEBUG フラグのメンテナンス負債を解消するため、削除プロセス・タイムライン・技術実装の詳細なルールを規定します。

ステータス変更

likely_accept → accepted
2026年6月3日、@aclements がproposal reviewグループを代表して正式に承認を宣言しました。ポリシー本文と主要なビルド時実装がまとまり、残る実装作業（起動時パニック・go vetサポート）はGo 1.27リリースに向けて継続される見込みです。

技術的背景

現状の問題点

Go 1.0互換性保証（2012年〜）を維持しつつ動作変更を行うため、GODEBUG 環境変数が導入されました。例えば panicnil=1 を設定すれば panic(nil) を Go 1.20以前の動作に戻せます。しかし13年間の積み重ねにより、フラグが乱立し次の問題が生じています。

• フラグごとに動作の分岐点が生まれ、テストの網羅性が低下
• 削除時期が不明確なフラグが多数存在し、メンテナンス負担が増大
• 既存ポリシーは「最低2年間維持」を定めるだけで、削除手順が未規定

提案された解決策

フラグを4カテゴリに分類し、それぞれの削除手順を規定します。
既存フラグのカテゴリ分類と対処

カテゴリ	対処
既に削除済み	履歴記録のみ
削除予定日あり	1リリース前に「削除予定」を宣言し、次リリースで削除
永続でも削除予定日もない	削除日を設定（導入から2年以上かつ半年以上先）した後、上記手順を適用
永続と明記されたもの	削除を正当化する個別proposalを提出し承認後に削除手順へ
新規フラグへのポリシー
新たに導入するフラグは「永続」か「導入から2年以上先の削除予定日あり」のどちらかを必ず明記しなければなりません。

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

このポリシーにより、Goチームとコミュニティは以下が可能になります。

• GODEBUG フラグの計画的なクリーンアップ（例: Go 1.27で削除予定の gotypesalias、asynctimerchan、tlsunsafeekm などの crypto 関連フラグ）
• フラグ廃止のタイムラインを事前にリリースノートで告知することによる、開発者への十分な移行期間の保証
• フラグ名の再利用防止のための履歴管理（internal/godebugs/table.go を活用）

コード例

// Before: 削除済みフラグを旧値で設定（Go 1.27以降はビルドエラー）
//go:debug gotypesalias=0   // ← 非デフォルト値: ビルド失敗
// After: 削除済みフラグを最終デフォルト値で設定（許容・無視される）
//go:debug gotypesalias=1   // ← 最終デフォルト値: ビルド成功（静かに無視）
// go.modでの設定も同様
// godebug gotypesalias=0   // ← ビルドエラー
// godebug gotypesalias=1   // ← 許容

起動時の環境変数でも同様の制約が適用されます。GODEBUG=gotypesalias=0 のように削除済みフラグに非デフォルト値を設定するとプログラムがパニックします（実装はGo 1.27向けに進行中）。

議論のハイライト

• 「Deprecated」という用語の回避: @FiloSottile の指摘により、deprecated（Go APIでは「削除予定ではない」の意味）という語を避け、「slated for removal（削除予定）」という表現に変更されました
• 削除後のフラグ設定の扱い: 削除済みフラグを最終デフォルト値で設定することは無視（許容）されますが、旧値（非デフォルト）の設定はビルドエラーまたは起動時パニックになります
• go vetとの統合: 削除予定フラグに非デフォルト値が静的に設定されている場合、go vet の「テストスイート」に含まれるチェックで警告されます（言語バージョンに依存しない）
• SetGODEBUG/GetGODEBUGの先送り: runtime パッケージへの SetGODEBUG・GetGODEBUG 関数の追加は複雑性が増したため、Go 1.28向けの別proposalに分離されました
• GOEXPERIMENTとの範囲区分: @dmitshur から GOEXPERIMENT 設定にも類似ポリシーが必要との指摘がありましたが、本proposalのスコープ外とされました