net/url: MustParse
要約
概要
net/url パッケージに MustParse 関数を追加する提案。regexp.MustCompile や netip.MustParseAddr と同様に、パースに失敗した場合はパニックを起こし、パース結果を直接返す便利関数を提供する。
ステータス変更
(なし) → active
2026-06-17のProposal Review Meetingにおいて、より汎用的な must.Do 提案(#54297)がlikely declineの方向性となったことを受け、元々 #54297 が出発点としていた url.MustParse を独立したissueとして改めて検討するため、activeキューに追加された。@neild が「この提案は本来 url.MustParse についてのものだった」と述べ、#79946 を新規作成してactive審査を開始した。
技術的背景
現状の問題点
url.Parse はエラーを返すため、パッケージレベルの変数初期化やHTTPリバースプロキシ設定など、URLが確実に正しいと分かっている場面でも複数行のボイラープレートが必要になる。
// Before: 毎回同じパターンを書く必要がある
var baseURL *url.URL
func init() {
var err error
baseURL, err = url.Parse("https://example.com/api")
if err != nil {
panic(err)
}
}
パブリックリポジトリのSourcegraph検索によると、func.*Must.*Parse.*\*url\.URL { パターンに多数ヒットしており、各コードベースが独自の MustParse ラッパーを書いていることが分かる。
提案された解決策
net/url パッケージに以下のシグネチャの関数を追加する。
func MustParse(rawURL string) *url.URL
パースが成功すれば *url.URL を返し、失敗すればパニックを起こす。regexp.MustCompile、netip.MustParseAddr、template.Must などの既存パターンと一致する設計。
これによって何ができるようになるか
コード例
// Before: ボイラープレートが必要
var proxy = func() *url.URL {
u, err := url.Parse("https://backend.example.com")
if err != nil {
panic(err)
}
return u
}()
// After: 簡潔に記述できる
var proxy = url.MustParse("https://backend.example.com")
主なユースケース:
- パッケージレベルの変数初期化(引数が定数であり失敗し得ないケース)
httputil.ReverseProxyなどHTTPユーティリティへのURL指定- テスト内でのテスト用URLの生成(テスト対象がURLパースそのものでない場合)
議論のハイライト
- 分離の経緯: もともと #54297 は
url.MustParseの提案として始まったが、汎用的なmust.Doの議論に発展した。2026年6月のreview meetingで汎用版がlikely declineとなり、元のurl.MustParseを独立issueとして切り出した。 - 汎用
mustパッケージの却下理由: 関数1つだけのためにパッケージを新設するのは概念的コストが大きいと判断。errors.Mustは命名が紛らわしく(エラーを生成するように読める)、testing.T.Mustはジェネリックメソッドの制約上難しかった。 - 標準ライブラリとの一貫性:
regexp.MustCompile、netip.MustParseAddr、uuid.MustParseなどの既存パターンとの一貫性を保つ観点から、url.MustParse追加には強い反対意見がなかった。 - 実際の需要: @bradfitz(Tailscale)などが自前の
must.Getを実装しており、実際のニーズは存在する。ただし純粋に定数引数のみのユースケースは思いのほか少なく、ほとんどは JSON マーシャリングや既知プレフィックスのURL検証などの用途が多い。 - 今後の審査: 2026-06-18のweekly proposal review meetingにて正式にactiveキューへ追加され、今後の会議で議論される予定。