C++26 DIS投票の結果

C++26 DIS投票の結果

C++26はDIS投票に失敗しました。私の知る限り、これはC++のドラフトとしては初めてのDIS投票での失敗です。C委員会のコンベンナーであるRobert Seacord氏は、SC22のどの言語標準もこれまで投票に失敗したことはないと述べており、WG21ダイレクショングループのメンバーであるDaveed Vandevoorde氏も、これ以前のC++ドラフトで反対票が1票でも入ったことはないと述べています。したがって、リフレクション、std::execution、ライブラリの堅牢化、そして契約（contracts）といった機能は、ISOが承認していないドラフトに含まれており、遅延がどれくらいになるかはまだ誰にもわかりません。

投票は2026年10月23日に締め切られ、C委員会のコンベンナーであるRobert Seacord氏は、翌日LinkedInで結果を投稿しました。

私の立場#

投票期間中は、このシリーズを中立に保ち、どちらかの側に人を誘導したくありませんでした。投票は終わったので、私の立場を述べることができます。

私は契約というアイデアを愛しており、C++20から削除されて以来、それらを惜しく思っています。私は常にAPIデザイン、ライブラリ、優れたインターフェース、フレームワークに関心があり、それが私がLEWGにいる理由でもあります。私が契約を好む理由は、その経験に基づいています。チェックは一つの利点であり、それは良いものです。プログラムは自身の仮定を検証できます。私が同じくらい重要視している第二の側面は、ドキュメンテーションです。シグネチャ内の前提条件や事後条件は、APIデザイナーの意図を記録するため、ユーザーは何を期待し、どのように関数を使用すればよいかを知ることができます。Doxygenやcppreference.comのようなドキュメンテーションシステムは、それを直接表示できます。コメントでも同じことを言うことはできますが、それが真実であり続ける保証はありません。コードから離れてしまい、誰も気づかない可能性があります。契約はコードの一部です。コンパイラは関数と一緒にそれをチェックし、チェックが有効な場合、違反は大きなエラーとして失敗するため、このドキュメンテーションが静かに古くなることはありません。Conceptsはすでに、コンパイル時に関数が受け入れる型に対して、これらの両方を提供しています。契約はまだ欠けている部分であり、実行時に値に対して同じことを行うものです。私は契約が標準に含まれることを望んでおり、今回それが実現しなかったのは残念です。私の好みは、それらを維持することです。もしこの結果、設計がより良くなるのであれば、それも良い結果です。

これは私にとって抽象的な問題ではありません。私はワークショップでC++26の契約を教え始めており、mp-unitsはC++26バージョンを使用しています。

数字#

パート2では、DISが満たすべき2つの条件を説明しました。ドラフトは両方を満たせませんでした。

20票の3分の2は14票の賛成が必要ですが、ドラフトは12票しか得られませんでした。22票の4分の1は5票の反対票を許容しますが、ドラフトは9票を得ました。どちらか一方だけでもドラフトを失敗させるには十分でした。

どの国がどのように投票したか#

公式結果には全ての国名が記載されています。9カ国が反対票を投じました：デンマーク、フィンランド、イラン、イタリア、日本、ルクセンブルク、ルーマニア、スペイン、スウェーデン。それぞれがコメントを添えて投票しました。フランスとアイルランドは棄権しましたが、コメントも送付したため、合計11カ国がコメントしました。ポーランドとアメリカ合衆国は棄権しました。私はポーランドの国内委員会のメンバーです。

コメント自体はまだ入手できません。ISO/IEC指令（パート1の2.6.5節）では、投票終了後12週間以内に、結果、委員会委員長の決定、およびコメントの全文を含む完全なレポートが必要です。2026年10月23日に締め切られた投票の場合、これは2027年1月中旬までです。委員会ドラフト段階では、WG21はこの種のレポートをN5028として公開しました。今回も同様に行われるかはわかりません。

ポーランドの棄権#

ポーランドのC++に対する立場は、ポーランド標準化委員会（KT 331）の技術委員会で決定されます。その投票では、ポーランドがDISを拒否し、ISOに技術コメントを送るべきかどうかが問われました。投票は可決されなかったため、ポーランドはISOに「棄権」と伝え、技術コメントを添えることはできませんでした。

私は集計結果を共有したり、誰がどのように投票したかを言うつもりはありません。これは内部投票であり、公開される可能性があるかはわかりません。ポーランドが何かを発言するか、全く何も言わないかを決定するのは、わずかな票数です。

ポーランドの投票は、別の理由でほとんど無効になるところでした。ポーランドの投票が締め切られる数日前、まだ定足数を満たすための票が不足しており、定足数がなければポーランドの立場は存在しませんでした。リストに載っている人々のうち何人かが転職していました。私はメールやLinkedInで静かな人々に連絡を取ろうとしましたが、いくつかのメールはバウンスしました。おそらく、そのアドレスが以前の雇用先のものだったためでしょう。

C++26がどのように進むべきか、あなたがどのように考えているかにかかわらず、以下の2点が重要です。

• あなたが国内委員会のメンバーであるなら、投票してください。 どのような票であっても、その投票はカウントされます。
• もしあなたがもはや参加できないなら、投票メンバーリストから削除されるよう依頼してください。 定足数はあなたをカウントするため、非アクティブなメンバーは、あなた以外の全員が定足数に達することをより困難にします。これは今回の投票だけでなく、今後の全ての投票に影響します。委員会事務局は、静かになった人を単純に削除することはできないため、依頼するのはメンバー次第です。

反対票の理由#

反対票は契約に関するものだったと確信しています。それが投票前に記録された反対意見でした。クロイドン総会でC++26を投票に送った際の2つの反対意見は、両方とも契約に関するものでした。委員会ドラフトに対するいくつかの国内委員会のコメントは、それらを削除するよう求めていました（パート2に表があります）。P4238R1は、国内委員会に対し、契約のデザインとそれが委員会でどのように進められたかについて反対票を投じるよう求めていました。9票の反対票は全て契約に関するものだと予想しており、コメントが公開されるまで確かなことはわかりません。

このシリーズを追っていない読者のために、これがその機能であり、パート1で詳細に説明しています。

#include <cmath>

double checked_sqrt(double x)
    pre (x >= 0.0)
    post (r : r >= 0.0)
{
  const double root = std::sqrt(x);
  contract_assert(!std::isnan(root));
  return root;
}

このコードは、これらのチェックのそれぞれが実行されるかどうか、または失敗した場合に何が起こるかを決定しません。ドラフトは4つの評価セマンティクス（ignore、observe、enforce、quick-enforce）を定義し、それらの間の選択を実装に委ねています。GCC 16では、コンパイラフラグで1つを選択できます。多くの論争は、この選択、つまり契約アサーションがビルドで削除される可能性のあるチェックなのか、それともプログラムが依存できる保証なのか、という点にあります（パート3）。パート4とパート5は、残りの部分をカバーしています。

今後どうなるか#

指令では、DISが失敗した場合の4つの行動方針が定められています。

• 8週間の投票期間を持つ、改訂されたエンクワイアドラフト（Enquiry Draft）を回覧する。
• コメントのために、改訂された委員会ドラフト（Committee Draft）を回覧する。
• ドラフト技術仕様（Draft Technical Specification）として発行する。
• プロジェクトをキャンセルする。

SC22の委員長は、SC22事務局およびWG21コンベンナーと協力し、ISO/IEC中央事務局と協議の上、最初の3つのうちの1つを選択します。キャンセルは、SC22全体が決定しなければならない唯一の選択肢です。WG21の役割は、コメントに対処し、方針を推奨し、必要であれば改訂ドラフトを準備することです。これを書いている時点では、どの選択肢が選ばれたかの発表は見ていません。

次のWG21会議は、2026年11月16日から21日までブラジルのブジオスで開催されます。結果発表後、委員会全体としては初めての会議となりますが、どうすべきかについての意見は分かれています。

• WG21が契約を変更または削除せずに、再度投票を求めるべきだと考える人もいます。P4433R0は、このための正式な提案です。また、新しい技術情報をもたらさない限り、削除を求めるコメントを拒否し、ブジオスでの投票で両方を確認するよう求めています。
• 他の人は、短期的な解決策は単純だと言います。P4238R1の著者の一人であるJ. Daniel Garcia氏は、Seacord氏の投稿の下に「短期的な解決策は単純で、問題のある機能を1つ削除すれば、標準の残りは非常に高い確率で承認されるだろう」と書いています。Vandevoorde氏の推奨は「契約をドラフトから削除し、ライブラリの堅牢化を維持するための調整を行う」ことになるでしょう。
• 初期段階の国内委員会のコメントの中には、技術仕様やホワイトペーパーを代わりに求めるものもありました。

私はブジオスで計画を見たいと思っています。そして、契約をどうするかだけを述べるのでは私には十分ではありません。もし残りの標準をリリースするために契約がC++26から外されなければならないなら、それは残念ですが、私はそれに耐えられます。他の全てがそれらと一緒に待つことは望みません。私はC++26の残りの部分ができるだけ早くリリースされるのを見たいです。

より難しい質問は、ここからデザインがどのように改善されるかということです。私が読んだ反対意見は、異なる方向を指しています。コンパイラによってチェックされるより強力な保証、ライブラリにおけるデザインのさらなる統合、まず技術仕様、オフにできないチェック。反対する全ての人が受け入れられる単一の代替案を見たことがないため、どの変更が全員を満足させるかを言うのは難しいと感じています。それが私の見方であり、間違っているかもしれません。

新しい版が発行されるまで、現在のC++標準はISO/IEC 14882:2024（C++23）です。

今日のあなたのコードへの影響#

コンパイラはワーキングドラフトの機能を実装しており、投票は既に提供されているものには影響しません。GCC 16は-std=c++26を受け入れ、Clangは-std=c++2cを持っています。GCC 16は実験的なC++26サポートの一部として契約を実装しており、Clangの実装はまだマージされていません。ベンダーがそのフラグの下でドラフトされた全ての機能を維持するかどうかは、各ベンダー次第であり、今日誰もそれを約束することはできません。

もしあなたのチームが既にC++26の機能を使用している、または学習している場合、現時点では何も元に戻す必要はありません。しかし、あなたのコンパイラが今日実装しているものはドラフトであり、公開される標準と一致しない可能性があります。

未解決の事項#

• コメントを送付した11カ国からのコメントのテキスト。
• ブジオスでWG21が推奨すること、どの行動方針が選択されるか、そしてそのスケジュール。

委員会が次に何を決定するかにかかわらず、コンパイラがC++26の契約を実装し続けることを願っています。一つの反対意見は、本番環境でのデプロイ経験の欠如であり、パート5は、その議論の両面を提示しています。この経験は、人々が使用できる実装なしでは得るのが難しく、これは鶏と卵の問題です。契約が次に投票されるとき、同じ反対意見が再び持ち上がるのは避けたいです。

より多くの情報が公開されたら、この記事を更新します。