#75129 go/build: deprecate ArchChar(..)

AIによる要約であり、誤りを含む場合があります。

概要

go/build パッケージの ArchChar 関数に、正式な Deprecated: マークを付ける提案です。この関数は Go 1.5 以降、どの引数を渡しても "?" とエラーを返すだけになっています。

ステータス変更

likely_accept → accepted
2026年10月1日の Proposal Review Meeting で likely accept になり、その後1週間で異論が出なかったため、10月8日に @aclements が「No change in consensus」として accepted を宣言しました。API の追加や動作の変更はなく、10年以上前から機能していない関数にドキュメント上の非推奨マークを付けるだけの変更です。そのため議論はほとんど行われていません。

技術的背景

現状の問題点

Go 1.4 以前のツールチェーンでは、アーキテクチャごとに1文字の識別子（amd64 なら 6、386 なら 8、arm なら 5）が使われていました。コンパイラやリンカの名前（6g、6l など）、オブジェクトファイルの拡張子（.6）、出力ファイル名（6.out）はこの文字から決まっていました。build.ArchChar(goarch) は、この文字を取得するための関数です。
Go 1.5 でツールチェーンが C から Go に移行し、ツール名は compile、link、.o、a.out に統一されました。それ以降、現在の実装は次のようになっています。

// ArchChar returns "?" and an error.
func ArchChar(goarch string) (string, error) {
	return "?", errors.New("architecture letter no longer used")
}

ドキュメントには「"?" とエラーを返す」と書かれていますが、Deprecated: マークはありません。そのため、pkg.go.dev、gopls（Go の言語サーバー）、staticcheck などのツールは、この関数を使っているコードを警告しません。

提案された解決策

ArchChar の doc コメントに // Deprecated: 段落を追加します。代わりになる関数は用意されません。この関数が担っていた役割そのものがなくなっているためで、新しいコードで使う理由はありません。実装は CL 698418（go/build: mark ArchChar() as deprecated）として提出されています。

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

静的解析での検出: staticcheck（SA1019）や gopls が非推奨 API の使用として警告するようになります。古いビルドスクリプトや、Go 1.4 時代のコードを引き継いだツールに残っている呼び出しを見つけやすくなります。
ドキュメント上の明示: pkg.go.dev では非推奨 API が折りたたまれて表示されます。新しい利用者が誤って使うことを防げます。
API 整理の一環: Go 1 互換性保証があるため関数は削除されません。それでも非推奨と明示することで、標準ライブラリの API 一覧が整理されます。

コード例

// Before: Go 1.4 以前の前提で書かれたコード（Go 1.5 以降は常にエラーになる）
ch, err := build.ArchChar(runtime.GOARCH)
if err != nil {
	log.Fatal(err) // Go 1.5 以降は必ずここに到達する
}
compiler := ch + "g" // 例: "6g"
// After: アーキテクチャに依存しない固定の名前を使う
// （ArchChar の呼び出しは削除する。代替 API はない）
compiler := "compile" // go tool compile
linker := "link"      // go tool link

ドキュメントの変更後は、次のような形になると考えられます。

// ArchChar returns "?" and an error.
// ...
//
// Deprecated: Do not use. As of Go 1.5, ArchChar always returns an error.
func ArchChar(goarch string) (string, error)

（Deprecated: の正確な文言は CL のレビューで決まります。上の文言は推測です。）

議論のハイライト

提案者は、Go 1.5 以降この関数は常にエラーを返し、アーキテクチャによって結果が変わらないことを根拠に挙げています。
代替関数は提供されません。ツール名や拡張子が固定値になったため、代わりの API を用意する必要がありません。
動作は変わりません。関数は互換性のために残され、ドキュメントに非推奨マークが付くだけなので、既存コードへの実行時の影響はありません。
2025年8月の起票直後に CL が作られていましたが、Proposal Review Meeting で扱われたのは約1年後でした。議論すべき論点がほとんどなかったため、likely accept から1週間で accepted になっています。

Go Proposal Weekly Digest

go/build: deprecate ArchChar(..)

要約

概要