メインコンテンツへスキップ
#75129likely_accept

go/build: deprecate ArchChar(..)

新規提案

要約

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

概要

go/build パッケージの ArchChar 関数に、Deprecated(非推奨)を示すコメントを付ける提案です。この関数は Go 1.5 以降、常にエラーを返すだけで実質的に機能していません。

ステータス変更

(新規) → likely_accept
2026年10月1日、@aclements がProposal Review Groupを代表して「likely accept」と判断しました。根拠は「上記の議論に基づき」とされ、Issue本文の提案がそのまま採用される見込みです。Issueには既に Proposal-FinalCommentPeriod ラベルが付いています。Issue上の目立った議論は、実装CLへのリンクとこの判断の2件だけでした。Go 1.5 から約10年間、何もしない関数として残っていたこと、そして代替APIが不要であることから、反対の余地が小さい整理的な変更だと考えられます。

技術的背景

現状の問題点

Go 1.4 以前のツールチェーンでは、アーキテクチャごとに1文字の識別子(amd64 なら 6、386 なら 8、arm なら 5)が使われていました。コンパイラ名(6g、8g)、リンカ名(6l)、オブジェクトファイルの拡張子(.6)、出力ファイル名(6.out)は、この文字から決まっていました。ArchChar はこの文字を返すための関数です。
Go 1.5 でツール名は compile / link、拡張子は .o、出力名は a.out に統一され、アーキテクチャ文字は使われなくなりました。現在の実装は次のとおりで、引数に関係なく "?" とエラーを返します。

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

ただし doc コメントに正式な Deprecated: 表記がありません。そのため、staticcheck や gopls などのツールは利用箇所を警告できず、pkg.go.dev でも非推奨として表示されません。

提案された解決策

ArchChar の doc コメントに // Deprecated: 段落を追加します。関数のシグネチャと動作は変わりません。代替関数は用意されず、「新しいコードでは使わないこと」とだけ案内されます。実装は CL 698418(go/build: mark ArchChar() as deprecated)で提出済みです。

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

  • 静的解析による検出: staticcheck(SA1019)や gopls が ArchChar の呼び出しを非推奨APIの利用として警告できるようになります。
  • ドキュメントでの明示: pkg.go.dev で非推奨として表示され、IDE の補完候補でも目立たなくなります。古いチュートリアルなどを見た開発者が誤って使うことを防げます。
  • レガシーコードの整理: Go 1.4 以前のビルドスクリプトや自作ビルドツールに残っている呼び出しを見つけ、削除するきっかけになります。

コード例

// Before: Go 1.4 以前を前提にした古いコード(現在は常にエラーになる)
ch, err := build.ArchChar(runtime.GOARCH)
if err != nil {
	log.Fatal(err) // Go 1.5 以降は必ずここに到達する
}
compiler := ch + "g"            // "6g" など。現在は存在しない
obj := "main." + ch             // ".6" など
// After: ArchChar を使わず、Go 1.5 以降の固定名を直接使う
compiler := "compile"           // go tool compile
linker := "link"                // go tool link
obj := "main.o"

議論のハイライト

  • 提案者は「Go 1.5 以降は常にエラーを返し、アーキテクチャによって結果が変わらない」ことを非推奨化の理由に挙げています。
  • 代替APIは提供されません。アーキテクチャ文字という概念自体がツールチェーンから消えたため、置き換えるべき機能がありません。
  • Go 1 互換性保証があるため、関数は削除されず、Deprecated: 表記だけが追加されます。既存コードはこれまでどおりコンパイルできます。
  • Issue上で反対意見や代替案は出ていません。CL が先に提出されており、レビューグループはそのまま likely accept と判断しました。

関連リンク