C++26がContractsを巡りISO投票で否決、GCC 16で検証

C++言語の次期標準規格であるC++26の草案は、2026年10月のISO投票で否決された。否決の原因となった対立は、Contractsという1つの機能を巡るものだ。WG21と呼ばれるC++委員会は、11月16日から21日までブラジルのブジオスで会合を開く。そこで、この機能を削除するか、外に移すか、もう一度投票するかを決める。その結果次第で、C++のプログラマーがこの標準でContractsを使えるかどうかが決まる。

C++26の投票で何が起きたか

投票の対象はDraft International Standard(国際規格原案)で、ISOが規格を発行する前の最後の全体投票にあたる。各国の標準化団体が票を投じる。The Registerは、賛成13、反対9、棄権12と報じた。ISOのルールでは、反対票は全体の25%以下でなければならない。

ほかの報道では、数字が少し異なる。Mondによるブログ記事とHFT Universityの分析は、どちらも委員会メンバーのRobert Seacordが投稿した数字に基づいている。それによると、投票権を持つ20の団体のうち賛成は12で、3分の2に必要な14に届かなかった。さらに22の団体のうち9が反対し、上限の5を超えた。HFT Universityによると、公式の結果はまだ公開されていない。Seacordの投稿ははっきりと述べている。「C++26の投票が完了した。残念ながら、不承認となった」。

HFT Universityは、反対票を投じた国を挙げている。

投票	国
反対	デンマーク、フィンランド、イラン、イタリア、日本、ルクセンブルク、ルーマニア、スペイン、スウェーデン
コメント付きで棄権	フランス、アイルランド
棄権	ポーランド、米国

各国の団体がContractsに反対した理由

Contractsを使うと、プログラマーは関数の宣言にチェックを書き込める。preと書く事前条件は、関数が呼ばれたときに成り立つべきことを示す。postと書く事後条件は、関数が戻るときに成り立つべきことを示す。contract_assert文は、コードの途中で条件をチェックする。

反対派を率いるのは、C++を生み出したBjarne Stroustrupだ。The Registerによると、彼は「P2900のコントラクトとその拡張は、C++の性質を変えようとするもので、C++にとって存亡に関わる脅威だ」と述べた。委員会メンバーのAndreas Fertigは、この設計を擁護した。「このテーマには何年も取り組んできた。現在の形で、何度も過半数の賛成を得ている」。

Mondの分析によると、少なくとも7か国の団体が変更を求めたが、退けられた。Contractsの削除を求めた団体もあった。無効にできないチェックを求めた団体もあった。少なくとも4つの団体は、ライブラリのコードに安全チェックを加える「強化された標準ライブラリ」をContractsに依存させないよう求めた。委員会はその結び付きを残した。

ブジオスでWG21が決められること

The Registerは3つの選択肢を挙げている。WG21はContractsを削除し、C++26の残りの部分を出荷できる。Contractsを、規格の外にある別文書のTechnical Specification(技術仕様書)に移すこともできる。あるいは小規模な修正を加えて、もう一度投票することもできる。

Mondによると、双方の立場を主張する論文が2本ある。P4433R0「Do not remove Contracts from C++26」は、削除すればライブラリ強化の規定も書き直す必要があると警告している。Vinnie FalcoによるD4420「Do Remove Contracts From C++26」は、その逆を主張している。The Registerによると、規格が遅れた場合、正式名称はISO/IEC 14882:2027になる可能性がある。

検証: GCC 16でのC++26 Contracts

GCCのサポート状況ページは、ContractsをGCC 16から利用可能としている。Clangのサポート状況ページは「No」としている。Tech AI Wireのテストでは、macOS 26上のARM64 Linux DockerコンテナでGCC 16.2.0を使った。小さなプログラムが、次のチェックを持つsafe_div(10, 0)を呼び出した。

int safe_div(const int a, const int b)
    pre(b != 0)
    post(r: r * b <= a)
{
    return a / b;
}

各ビルドではg++ -std=c++26 -fcontracts -O2に、-fcontract-evaluation-semantic=のモードを1つ加えた。

モード	safe_div(10, 0)での動作	終了コード
enforce(デフォルト)	違反を出力し、その後中断した	134
observe	違反を出力し、実行を続け、0を出力した	0
quick_enforce	コントラクトのメッセージなしで中断した	134
ignore	チェックは一切なし。0を出力した	0

ignoreとobserveのビルドは、どちらも10を0で割った結果として0を出力した。意味のない答えだ。違反レポートには、ファイル、行、条件が示される。contract violation in function int safe_div(int, int) at contracts.cpp:4: b != 0。

知っておくべきビルドエラーが2つある。最初の試みでは普通のint a, int bを使い、GCCはこれを拒否した。「a value parameter used in a postcondition must be const」(事後条件で使う値引数はconstでなければならない)。また、-std=c++26だけで-fcontractsを付けないビルドは、コンパイルは通った。しかしリンク時に、handle_contract_violationへの未定義参照で失敗した。

テストでは、事前条件だけを付けた関数について、コンパイル後の機械語命令の数も数えた。手書きのif (b == 0) std::abort();は6命令だった。quick_enforceは11命令、enforceは15命令だった。-fno-contracts-conservative-ipaを加えると、それぞれ6命令と9命令に減った。GCCのドキュメントによると、このオプションは、インライン関数の本体をまたいでコンパイラーが最適化してよいかどうかを制御する。HFT Universityも、x86プロセッサーで同じ傾向を報告している。

開発者にとっての意味

まだ標準のContractsを前提にコードベースを計画しないこと。この機能はブジオスで削除、延期、変更される可能性があり、11月21日以降のWG21の報告でどれになるかがわかる。今日GCCの-fcontracts向けに書いたコードは、修正が必要になるかもしれない。

それでもGCC 16で試すなら、モードは意図して選ぶこと。ignoreとobserveは、チェックが失敗しても実行を続けさせる。そのため、安全のためではなくログ記録に向いている。事後条件が引数を読むときは、その引数をconstにすること。quick_enforceのコストを信用する前に、自分のホットパスで普通のifと比べること。ライブラリの強化機能に頼っているなら、会合の後もそれがContractsと結び付いたままかを見守ること。