C++26が壁に直面。ある機能がその原因に

C++26の標準化への道のりは、2026年10月24日、前例のない障害に直面しました。ドラフトはISO Draft International Standard (DIS) ballotで不承認となり、C++の標準規格がこの重要な段階で否決されたのは史上初めてのことです。このオール・オア・ナッシングの投票では、個別の機能ではなく、ドラフト全体を承認することが加盟団体に求められていました。

投票結果は厳しいものでした。参加メンバーのうち賛成は60%（20カ国中12カ国）にとどまり、必要な3分の2の過半数に達しませんでした。さらに、22の加盟団体のうち9団体が「反対」を投じ、不承認の許容上限である25%を大きく超える41%という驚くべき数字に達しました。これはC++の廃止やC++26の全機能の全面否定ではなく、ある一つの論争的な提案に対する深い意見の相違に起因する、パッケージ全体への決定的な拒絶でした。

この結果は、各国の加盟団体が単なる追認機関ではないことを裏付けています。不承認は、ドラフト化されたC++26標準がそのままでは進められないことを意味します。コミュニティは現在、ドラフトの再評価と修正という複雑な課題に直面しており、リリースが大幅に遅れる可能性があります。

C++26のランタイムチェックとして提案されたContractsが、議論の余地のない破談の原因となりました。P2900で詳述されたこの機能は、preconditions（事前条件）、postconditions（事後条件）、assertions（アサーション）を言語に直接組み込み、開発者がプログラムの期待される状態や動作を指定できるようにすることを目的としていました。

これは小さな追加機能ではありませんでした。Contractsだけでドラフト標準を約56ページも膨らませました。この提案では、ignore、observe、enforce、quick-enforceという4つの実装定義の評価モードが指定されていました。さまざまな展開シナリオに適応させることを意図したこの柔軟性が、逆に大きな反対を招くことになりました。

C++の生みの親であるBjarne Stroustrup氏を含む批評家たちは、Contractsを危険を孕んだ巨大で不完全な設計であると見なしました。彼らは、それが不必要な複雑さやundefined behavior（未定義動作）の新たな経路をもたらし、さらに「本番ビルドでは無効化される（そしておそらく無効化されるであろう）ランタイムチェック」という根本的な設計上の欠陥があると主張しました。彼らは、これがC++の核となるゼロオーバーヘッドの原則を損ない、現代の静的解析でより適切に対処できる問題に対して1980年代の解決策を提示していると論じました。

C++の生みの親であるBjarne Stroustrup氏は、単にContractsを嫌っただけでなく、反対運動の先頭に立ちました。8月、Stroustrup氏と4人の共著者（J. Daniel Garcia氏、Vinnie Falco氏、John Spicer氏、Ville Voutilainen氏）は、P4334R0 “P2900 Contracts' Fundamental Flaws” を発表しました。この論文は、この提案を「C++に対する実存的な脅威」と呼び、そのアプローチを「約50年の進歩を無視した1980年代のアプローチ」として退けました。

根本的な設計の分断は明白です。Stroustrup氏を含む批評家たちは、一貫した静的解析と堅牢な安全性保証を提唱し、ランタイムのみのチェックは本番ビルドから削除されることでC++のゼロオーバーヘッドの原則に違反すると主張しています。また、彼らはこの提案が新たな未定義動作のリスクと、実証されていない継承モデルをもたらすと論じました。

一方、支持者はランタイムのContractsを、プログラムの前提条件を表現・検証するための実用的かつ即座に役立つツールであり、現代の開発に不可欠な機能であると見なしています。提案の詳細については、P2900: Contracts for C++ を参照してください。

Stroustrup氏の「ゼロオーバーヘッド」への懸念に対する反論も同様に説得力があります。機能する標準化プロセスとは、委員会による妥協案を無批判に承認するのではなく、提案をこれほど深く精査すべきだというものです。C++26の否決は、各国の代表機関が注意深く監視しており、たとえ標準化が遅れたとしても、新機能が最高水準を満たすことを保証している証拠です。これは単なるContractsの問題ではなく、標準化プロセス全体の誠実さに関わる問題です。

C++26の投票が「全か無か」という性質のものであるため、Contractsが単独で失敗しただけでなく、標準規格全体が道連れになりました。static reflectionやstd::executionといった期待されていた機能も、現在宙に浮いた状態です。この付随的な被害は、進歩を熱望するコミュニティにとって苦い薬となりました。

この膠着状態は、C++がソフトウェアの安全性と信頼性を向上させるための厳しい監視に直面している中で起こりました。RustやSwiftといった競合言語は、メモリ安全性と堅牢な並行処理モデルを提供しており、C++標準化委員会に対して進化を迫っています。業界は単なるパフォーマンス以上のもの、すなわち証明可能な正確性を求めているのです。

現在、委員会は困難な進路を決定しなければなりません。選択肢としては、各国のコメントを再検討して懸念に対処するか、あるいはより抜本的に、スケジュールを救うためにContractsを完全に削除するかが挙げられます。より限定的な妥協案が浮上する可能性もありますが、最終的な進路とそのタイムラインは依然として極めて不透明です。今回の投票は、一つの機能が実際にすべてを停滞させ得ることを証明しました。

なぜC++26のドラフトはISO投票で否決されたのですか？

ドラフトが必要な承認基準を満たせず、許容される反対票の割合を超えたためです。Contracts提案をめぐる意見の不一致が、主な原因であると広く見なされています。

C++におけるContractsとは何ですか？

Contractsは、実行時にチェック可能な事前条件、事後条件、およびアサーションを表現するための提案中の言語機能です。

投票によってC++26のすべての機能が拒否されたのですか？

投票はドラフト標準全体を対象としていたため、ドラフト全体が否決されました。ソースで説明されている異議は主にContractsに向けられたものであり、すべてのC++26機能が否定されたわけではありません。

投票失敗後、C++26はどうなりますか？

委員会は各国の代表機関からのコメントを検討し、Contractsを削除するか、提案を修正するか、あるいは別の道を探るかを決定しなければなりません。リリースのタイムラインは不透明です。