概要

Go言語のString()メソッドとGoString()メソッド（fmt.Stringer/fmt.GoStringerインターフェース実装）を既存の型に追加する変更について、通常必要となるproposalレビュープロセスを免除する、というメタproposalです。

ステータス変更

active → likely_accept
複数回の proposal review meeting での議論の結果、「デバッグ用の人間可読な文字列を返す明白な String メソッド」については proposal review を経ずにコードレビューのみで追加できる、という方針で likely accept となりました。ただし、文字列フォーマットについて何らかの互換性保証をする場合（あるいは既存の未規定な String メソッドの出力を仕様として固定する場合）は、引き続き proposal review が必要とされています。

技術的背景

現状の問題点

Goの標準ライブラリやツールチェインの型に、デバッグ出力目的で単純な String() string や GoString() string メソッドを追加したいだけの場合でも、通常のproposalプロセスを通す必要があり、1〜2ヶ月の審議期間がかかっていました。こうした変更は多くの場合、文字列フォーマットについて厳密な仕様を約束するものではなく、実質的に議論の余地が少ないにもかかわらず、proposal委員会のレビューリソースを消費していました。

提案された解決策

提案者（@aclements）は、以下のような「文字列の構文について曖昧な言及しかしない」String/GoStringメソッドの追加は、proposalプロセスの対象外（exempt）とすることを提案しました。

+ // 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

レビュー会議での議論を経て、方針は次のように整理されました。

• 「人間可読なデバッグ用文字列」を返すString/GoStringメソッドはproposal reviewなしで、2名のレビュアーによるCLレビューのみで追加可能とする。
• 一方、文字列フォーマットについて何らかの保証（互換性コミットメント）をする変更は、引き続きproposal reviewが必要。
• MarshalTextのように文字列の内容自体がプロトコルの一部となるものはこの免除対象外。

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

Go標準ライブラリの開発者は、デバッグ目的のString/GoStringメソッドを追加する際に、proposalの起票・数週間の審議を経ずに、通常のCLレビュー（2名のレビュアー承認）だけで変更を進められるようになります。これにより、開発サイクルの高速化とproposalレビュー委員会の負荷軽減が期待されます。

コード例

// Before: String()メソッドを追加するだけでも正式なproposalが必要
// → issue起票 → 1〜2ヶ月の議論・審議 → 承認後に実装CLを提出
// After: 明白なデバッグ用String/GoStringメソッドは、
// 通常のCLレビューだけで追加可能（proposal不要）
// 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)
}

議論のハイライト

• String化できない型が存在するのは問題ではなく、この提案はあくまで「String化が妥当な場合」の障壁を下げることが目的（@aclements）。
• @dmitshurは、提案例文中の「a fuller description than String」という表現が、fmt.GoStringer公式ドキュメントの「Go構文を定義する」という説明と乖離している点を指摘し、既存インターフェースの高レベルな期待に沿うことを条件とすべきと提案。
• Hyrum's law（実装の詳細に依存する利用者が現れる法則）を踏まえ、Stringの出力結果は明示的に約束しない限り互換性保証の対象にすべきでない、という原則が確認された。
• MarshalTextのような、文字列の内容そのものがプロトコル・仕様となるメソッドはこの免除の対象外とすることで合意。
• Austin Clements（@aclements）が別途「trivial proposal」向けのファストトラックプロセスの導入を計画しており、本proposalはそのプロセスが整うまでの暫定的な試験運用として承認する方向となった。
• 型を3カテゴリ（1. メールアドレスのように自然な文字列表現を持つもの、2. strings.Builderのように文字列構築自体が目的のもの、3. 自然な文字列表現を持たないもの）に分類し、この提案はカテゴリ3を主対象とすることが議論された。