C++の生みの親が36年ぶりに反旗、C++26のDIS否決を招いた「創設者と所有者の対立」

Herb Sutter: When a language's creator and its owners strongly disagree [pdf]

C++26のDIS投票が史上初めて否決された。原因はcontracts機能をめぐり、WG21が強いコンセンサスを持つ一方で、言語の生みの親Bjarne Stroustrupが「設計が根本的に欠陥」として反対したことにある。Herb Sutterは、C、JavaScript、Perl、Python、Rustなど他言語でも起きた創設者と所有者の対立の歴史を整理し、C++26の進むべき道を率直に論じる。

C++26 contractsの「設計は根本的に欠陥があり、新たな不安全要素を加え、主要な機能を実装定義のままにし、違反処理を制限し、オーバーヘッドを増やし、不完全で、追加と修正を要し、セマンティクスをコンパイラスイッチで決めるなどしている」
  1. pornel

    Stroustrupの反対意見のリストは、私にはかなり理にかなっているように聞こえる: https://www.stroustrup.com/Contracts_fundamental_flaws.pdf

  2. StellarScience

    これはHerb Sutterによる、よく書かれた非常に外交的な要約だ。彼が「Stroustrupの反対が、他のものが通ったのにC++26の投票が失敗した主な理由だ」という点で正しいかどうかを確信できるほど私は事情に通じていないが、もっともらしく聞こえる。

    この文書はまた、C++26に向けた6つの可能な道筋を長所と短所とともに挙げている。私の理解では、おおよそ次のとおりだ:

    A. 公式のC++26標準をスキップし、これらの機能をC++29に盛り込む。

    B. C++26からcontractsを外して可決する。

    C. 「お願いします」と言って、もう一度投票する。

    D. 仮想関数に関するcontractsを微調整して、もう一度投票する。

    E. C++26を国際標準ではなく、多くの異なる国の国家標準として可決する。

    F. Eを行い、さらにISOを離脱して代わりにANSI/INCITSに移行することも検討する。

  3. digitalPhonix

    これはこの出来事とcontractsに対するBjarneの立場に重きを置きすぎていると思う。contractsに対するBjarneの反対が形勢を逆転させたのかもしれないが、実装者への宿題として放り投げられた、大規模で中途半端な機能に対する疲労感(そして警戒心)が確実に高まっている(modulesのことだよ、君のことだ)。

    この投票を分析する際にそうした歴史的文脈を無視するのは、間違いのように思える。

  4. yakaccount4

    しばらくC++にはあまり注意を払っていなかった(最後に目にした素敵な機能はconceptsだった)。普段は、新機能で書ける奇妙で表現豊かなコードゴルフを結構楽しんでいる。例えば、Matrixの次元が目的の演算と互換性があることを保証するためにconceptsを使ってみた。それほど役に立つわけではないが、面白い思考実験だった。

    しかし、これらの提案されているcontractsは…自分で明示的にassertionを書くのに比べて、それほど大きな利点があるようには思えない。

    宣言の中に要件が見えるというのはあるかもしれないが、現代の凝ったC++の宣言はすぐに長く冗長になって、読んでいるとすぐに疲れてしまうだろうと賭けてもいい。もしかするとLLM時代にはもっと役に立つのかもしれない?

  5. Routine8502

    C++を始めようと数週間費やしたことがある者として(LLM以前の話なので、今はもっと良いかもしれない?)、混乱してほとんど諦めてしまったのだが、何かをするのに複数の異なる方法があるのに対処するのが本当に大変だと感じた。つまり、どのポインタを使えばいいのか?どうイテレートすればいいのか?これにはきっと答えがあるのだろうが、単純にpythonに戻って、必要ならrustを開く方が楽だと感じた。

    懸念の一部は、機能は一度きり正しく出荷する必要があるということのようだ。なぜなら永遠に生き続けるからだ。ならば、機能を非推奨にしてから削除できるようにすれば助けになるのではないか?

    でもわからないな、私は36年も生き続けるものを書いたことがないから、今のアプローチが最善なのかもしれない!

  6. kikoreis

    ちょっと立ち寄って言っておくと、SutterはここでBjarneの立場を繰り返し述べるのが正しいだけでなく、ハードウェア性能の進歩と並行実行への移行に関する、私見では最も影響力のある論文の著者でもある: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf

  7. kazinator

    36年間にわたる持続的な合意は良いことではない。それは誰も何に対しても「ノー」と言っていないということであり、巨大で汚れた雪だるまが山を転がり落ちているということだ。

  8. socalgal2

    私だけではないと確信しているが、C++はもう終わりだ/おしまいだと感じている。私はC++のコードベースで働いていて、20年以上C++をやってきたが、少なくとも私には、もう兆候は明らかだ。

    1. C++は安全でない。Bjarneは「完璧に使って一切ミスをしなければ安全だ」と事実上言う講演を続けている。それはもう役に立たない。LLMが悪用すべきあらゆるミスを見つけられる世界では、すべてのC++プロジェクトが追いつくのに苦労しており、それらをC++のままにしておくことは、将来さらに多くのエクスプロイトが生まれることを事実上保証している。そう、より安全な言語に切り替えてもすべてのバグが解決するわけではないが、新たな現実において攻撃対象領域を減らすことは、もはや先延ばしにできることではない。

    2. LLMは書き換えられる。以前の議論は「C++のレガシーコードベースがあるからC++は決して死なない」というものだった。それはLLMが全部書き換えてしまう前には妥当な議論だった。完璧ではないと言う人がいるのはわかるが、人間も完璧ではない。さらにLLMは常に良くなっており、その進歩を我々は目にしている。LLMをあるプロジェクトに向けると、それが魔法のように別のプラットフォームで動くようになる、といった話も見る…それが起きているのは明らかだ。

この日のほかの記事

2026-11-09