attractive nuisance

attractive nuisance は英米法の用語で、子供を引き寄せてしまう危険な設備 (例えば柵のないプール) を放置した土地所有者の管理責任を指す「誘惑的危険物」の法理である。Go の proposal レビューでは、これを転用して**「一見便利で人を引き寄せるが、広く使われるとエコシステム規模で害になる API」**という意味で使う。

実例が #54297 "proposal: must: Do" の却下である。エラーが出たら panic する汎用の must.Do 相当の関数をライブラリとして標準に入れようという提案だったが、2026-06-25 に declined された。aclements の最終コメントが判断基準をそのまま示している。

testing.T.Must alone unfortunately seems to be an attractive nuisance. A general must.Do (whatever you call it) seems an even riskier attractive nuisance: an incremental nicety that could have very negative effects at ecosystem scale. We've seen misuse even of the existing one-off *Must APIs that has led to outages.

ポイントは、個々の利用シーンでの便利さと、エコシステム全体に広まったときの影響を明確に分けて評価していることである。しかも「既存の一部の *Must 系 API の誤用で実際に障害が出ている」という具体的な実害が、判断の決め手として挙げられている。抽象的なリスク論ではなく、既に起きた事故が根拠になっている点が特徴的である。

この却下は、must: Do が却下された理由 で見るように「言語機能が入ったからといって、それが標準ライブラリの API として入るとは限らない」ことを示す例になっている。ジェネリクスメソッドという言語機能の追加自体は 2026-05-26 に決着しているが (提案 #77273 "A change of view.")、それが must.Do のような具体的な標準ライブラリ API の採否を自動的に決めるわけではない。

Go チームの判断基準としては、ianlancetaylor の "write code rather than designing types" という言い回しも近い型として挙げられる。これは #80448 (generic associated type) の却下理由で使われたもので (generic associated type と Go の判断基準)、「便利そうに見える抽象化が、実際にコードを書きやすくするか」という同じ物差しを異なる角度から表している。

出典

• Go Release Party 1.27 の発表資料リポジトリ memo.md §4 (issues.md 由来)
• Go Release Party 1.27 の発表資料リポジトリ issues.md §4
• #54297