概要

Goの標準ライブラリで型に String() メソッドや GoString() メソッドを追加するだけの単純な変更について、通常のproposalレビュープロセスを経ずに、コードレビューのみで承認できるようにするメタ提案です。

ステータス変更

likely_accept → accepted
2026年7月15日にaclements氏が「likely accept」と判断した後、1週間の最終確認期間を経て異論がなかったため、7月23日に正式に「accepted」となりました。議論を通じて、こうした軽微な変更をproposalプロセスの重い手続き（1〜2ヶ月の待機期間など）に載せること自体が非効率であるという共通認識が形成されたことが決定の背景にあります。

技術的背景

現状の問題点

Goの標準ライブラリでは、既存の型に人間可読なデバッグ用文字列を返す String() メソッド（fmt.Stringer の実装）を追加するだけの些細な変更であっても、正式なproposalプロセスを通す必要がありました。これは提案から承認まで1〜2ヶ月かかることもあり、実質的な設計論争がほとんどない変更に対しては過剰な手続きコストとなっていました。

提案された解決策

以下のような、既存の型に「文字列の構文について曖昧な説明しかしない」String/GoString メソッドを追加するだけの変更は、proposalレビューの対象外とすることが認められました。

+ // String returns a human-readable representation of a Thing suitable for debugging.
+ func (Thing) String() string
+ // GoString returns a fuller description of a Thing than [Thing.String].
+ func (Thing) GoString() string

ただし、レビュー議論の中で重要な線引きが明確化されました。文字列のフォーマットを具体的に保証・固定する変更（つまり出力形式が仕様として扱われるようなもの）は、Hyrum's law（実装の詳細に依存するユーザーが現れるという経験則）の観点からも、引き続き通常のproposalレビューが必要とされます。あくまで「人間が読むためのデバッグ用文字列」であることが条件です。

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

標準ライブラリの開発者が、デバッグ表示のための String()/GoString() メソッドを追加したい場合、proposal issueを立てて数週間の審査を待つ必要がなくなり、通常のコードレビュー（2名のレビュアーによる承認など）だけで変更を進められるようになります。これにより、実用上有用なデバッグ用文字列メソッドの追加が迅速化され、開発者体験の細かな改善がスピーディに標準ライブラリへ取り込まれやすくなります。

コード例

// Before: String()を追加したいだけでも正式なproposal issueを立てて
// 1〜2ヶ月のレビュー待ちが必要だった
// (例: proposal: crypto: crypto.Hash implement fmt.Stringer のような個別issueを都度作成)
// After: 曖昧な文字列表現であれば、通常のCLレビューだけで追加可能
// String returns a human-readable representation of a Thing suitable for debugging.
func (t Thing) String() string {
    return fmt.Sprintf("Thing{Name: %q, ID: %d}", t.Name, t.ID)
}

議論のハイライト

• aclements氏は、すべての型に String メソッドを付けるべきという話ではなく、「意味がある場合にのみ、その追加のハードルを下げる」ことが目的だと明言しました。
• dmitshur氏は、GoString の説明が fmt.GoStringer の公式ドキュメント（「Go構文を定義する」）と乖離しないよう、曖昧な説明であっても fmt.Stringer/fmt.GoStringer インターフェースの本来の趣旨から逸脱すべきではないと指摘しました。
• レビュー会議では型を3分類する議論がなされました。(1) メールアドレスのように自然な文字列表現を持つもの、(2) strings.Builder のように文字列構築自体が目的のもの、(3) 自然な文字列表現を持たないもの。本提案は主に(3)のカテゴリを対象としています。
• MarshalText のような、文字列の内容が明示的なプロトコル（契約）となるメソッドはこの緩和の対象外とすることが確認されました。
• 将来的にAustin氏（aclements）が構想している「trivial proposal」向けの高速レビュートラックが導入されれば、本件もそちらに統合される可能性があるとされましたが、それを待たずにまず本方針を試行することが決定されました。