メインコンテンツへスキップ

Go Proposal Weekly Digest

Go言語のproposal更新を毎週お届け

#79946active

net/url: MustParse

新規提案

要約

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

概要

net/url パッケージに MustParse 関数を追加する提案。regexp.MustCompilenetip.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.MustCompilenetip.MustParseAddrtemplate.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")

主なユースケース:

  1. パッケージレベルの変数初期化(引数が定数であり失敗し得ないケース)
  2. httputil.ReverseProxy などHTTPユーティリティへのURL指定
  3. テスト内でのテスト用URLの生成(テスト対象がURLパースそのものでない場合)

議論のハイライト

  • 分離の経緯: もともと #54297 は url.MustParse の提案として始まったが、汎用的な must.Do の議論に発展した。2026年6月のreview meetingで汎用版がlikely declineとなり、元の url.MustParse を独立issueとして切り出した。
  • 汎用 must パッケージの却下理由: 関数1つだけのためにパッケージを新設するのは概念的コストが大きいと判断。errors.Must は命名が紛らわしく(エラーを生成するように読める)、testing.T.Must はジェネリックメソッドの制約上難しかった。
  • 標準ライブラリとの一貫性: regexp.MustCompilenetip.MustParseAddruuid.MustParse などの既存パターンとの一貫性を保つ観点から、url.MustParse 追加には強い反対意見がなかった。
  • 実際の需要: @bradfitz(Tailscale)などが自前の must.Get を実装しており、実際のニーズは存在する。ただし純粋に定数引数のみのユースケースは思いのほか少なく、ほとんどは JSON マーシャリングや既知プレフィックスのURL検証などの用途が多い。
  • 今後の審査: 2026-06-18のweekly proposal review meetingにて正式にactiveキューへ追加され、今後の会議で議論される予定。

関連リンク