debug/pe: deprecate ImportDirectory
要約
概要
debug/peパッケージが15年前から公開しているImportDirectory構造体を、実質的に使い道がないまま放置するのではなく、正式に「非推奨(Deprecated)」としてドキュメント化する提案です。
ステータス変更
** → likely_accept**
2026-09-24のproposal reviewミーティングにて@aclementsが「likely accept」と判定しました。議論はシンプルで、ImportDirectoryが実質的に誰にも使われておらず、意図せず公開されてしまった内部実装の詳細であることが明確だったため、大きな異論なく承認の方向で進んでいます。
技術的背景
現状の問題点
debug/pe.ImportDirectoryはPEファイル(Windows実行形式)のインポートディレクトリテーブルの1エントリを表す構造体ですが、go/codereview 3733046(2011年、約15年前)で導入されて以来、ドキュメントすら一切書かれていませんでした。パッケージ保守者の@alexbrainman氏が2025年にGitHub上のコード検索(language:Go "pe.ImportDirectory")を行った結果、この構造体を実際に活用しているコードは見つかりませんでした。つまり公開APIとして存在するものの、実用上意味のある使い方が確立されていない状態です。
さらに約9年前(CL 22182)の時点で、既に「ImportDirectoryをどう扱うか決める」というTODOコメントがソースコードに残されていましたが、後方互換性の制約上、削除するとdebug/peパッケージを利用する既存コードを壊す可能性があるため、そのまま放置されてきました。
提案された解決策
構造体自体は互換性のため削除せず維持しつつ、Goの標準的な// Deprecated:コメント規約に従ってドキュメントコメントを追加します。あわせてapi/next/ファイルにAPIの非推奨マーキングを登録し、リリースノート(doc/next/)にも変更内容を明記します。これによりgo vetのstaticcheckなど、Deprecatedアノテーションを検知するツールが警告を出せるようになります。
これによって何ができるようになるか
この変更自体は新機能の追加ではなく、既存の「誰にも使われていない・使うべきでない」APIを明示的に告知するものです。開発者にとってのメリットは、IDEの補完やlintツール(staticcheckなど)がこの型の利用を警告してくれるようになり、誤って使ってしまうことを防げる点にあります。また、将来的にdebug/peパッケージがより整備された(例えばインポートテーブルを安全に扱う)APIを提供する際の布石にもなります。
コード例
// Before: ImportDirectoryにドキュメントがなく、
// 何のための構造体か、正しい使い方も不明なまま公開されていた
type ImportDirectory struct {
OriginalFirstThunk uint32
TimeDateStamp uint32
ForwarderChain uint32
Name uint32
FirstThunk uint32
}
// After: Deprecatedコメントが追加され、内部実装の詳細であり
// 直接使うべきでないことが明示される
// ImportDirectory represents an entry in a PE file's import directory table.
//
// Deprecated: ImportDirectory is an internal detail and should not be used directly.
type ImportDirectory struct {
OriginalFirstThunk uint32
TimeDateStamp uint32
ForwarderChain uint32
Name uint32
FirstThunk uint32
}
議論のハイライト
- 発端は
debug/pe.ImportDirectoryへのドキュメント追加を試みたCL(CL 679457)のレビュー中に、そもそもこの構造体が「意図せず公開されてしまった内部実装の詳細」であることが再確認されたことです(issue #15345のコメント参照)。 - @alexbrainman氏はGitHubコード検索により、
pe.ImportDirectoryを実際に活用しているオープンソースコードが見当たらないことを確認し、「削除すべきだが、公開APIである以上互換性の観点から難しい」と指摘しました。 - 妥協案として「削除ではなく非推奨化」が採用され、実装CL(CL 813961、作者: Ilya Torbin氏)で
// Deprecated:コメントの追加とAPIファイルへの登録が行われました。 - proposal reviewでは@aclementsが特段の反対意見なく「likely accept」と判定しており、後方互換性を壊さない軽微な変更であることから、議論は短期間でまとまっています。