【海外の反応】C++26が投票で異例の否決、contractsで意見対立
姉妹サイトの新着
C++の次期規格「C++26」が、ISOの最終承認段階であるDIS(Draft International Standard)投票で否決されるという、標準化史上初めての事態が起きた。原因とされるのが、関数の事前条件・事後条件をチェックする新機能「contracts」で、同じ草案に含まれていたreflectionやstd::execution、library hardeningといった注目機能も一緒に足止めされている。Hacker Newsのスレッドでは、否決は「信頼を揺るがす異例の行動」なのか「二段階承認という仕組みが正しく機能した結果」なのか、contractsと既存のconceptsの違いが分かりにくいこと、AI時代にcontractsのような機能がどう役立つかなど、立場の異なる声が交わされた。
C++26、承認されず
出典: andreasfertig.com / 元記事はこちら
std::regex(という名前だったか)をもう少し速くしてほしいね。利点もないのに恐ろしく遅いらしいから。
これが実現しない主な理由は、C++の事実上安定したABI(公式にはそんなものは存在しないとされているが)を壊してしまうからだ。詳しい背景は当時の論文を見てほしい。ネタバラシすると、「絶対に避けてほしいリーダーシップの失敗」と呼ばれていた選択が、結局そのまま起きてしまった。
rangesもまだ改善の余地がかなりある。
自分も理解できない。どちら側にも肩入れしてないけど(C++を書かなくなって何年も経つが、昔は書いていた)。今の時点でこれを規格に入れるべきかどうかについて、本当に意見が分かれているようで、これはむしろプロセスが設計どおりに機能している例に見える。
SIMD/AVXを統一しようとするフレームワークはあるけど、その抽象化はタダじゃない。今必要なのはより良い抽象化じゃなくて、より良いハードウェアと低レベルインターフェースだと思う。
「c++ contracts」とかで検索すれば情報はたくさん出てくるよ。要するに、関数の事前条件・事後条件みたいなもの。assertを少し強化したものだと思えばいい。
正直かなり内輪向けの記事だよね。Contractsはプログラムの状態についてのアサーションをもっと柔軟に書けるようにする、提案中のC++の言語機能。要はC言語のassert関数のC++版強化みたいなもので、事前条件・事後条件のようなもっと複雑な条件を関数に付けられるようにして、安全性とパフォーマンスの両方を理論上改善するもの。
メモリ安全性は1959年、Lispの発明によって既に解決済みだよ。
君が使ってるRustも、だいたいはC/C++の環境の上で動いてるよ。
今回の提案自体を擁護するわけじゃないけど、contractsみたいな仕組みは、自動テストや静的型付けと同じ理由で、AIコーディングとかなり相性がいいと思う。
多くの人、特に能力の高いプログラマーほど、過去の戦争を戦い続けている。AIなんてそのうち消えて、また2019年みたいな感覚で仕事ができると思ってるみたいだ。
君のコメントを読んで気づいたんだけど、contractsってconcepts(要はバウンデッドジェネリクスだよね…?)とは別物なんだ。
Conceptsはコンパイル時に評価されて、テンプレートメタプログラミングをずっとエレガントにしてくれるもの。Contractsはランタイムチェックで、アサーションに近い。言い方を変えると、contractsとconceptsの関係は、assertとstatic_assertの関係と同じ。
conceptはテンプレート(C++でのジェネリクス)を制約するコンパイル時の要件のことだから、君の理解はだいたい合ってる。
Conceptsは型についてのコンパイル時の仕組みで、Contractsは値についてのランタイムの仕組み。
問題は、contractsを気に入らなかった一部の人たちが、C++26の承認に反対票を投じるというかなり極端な行動を取ったことだ(それと、君はcontractsが何なのかよく分かってないみたいだね)。
他サイトの新着
は?Conceptsは型の型みたいなもので、Contractsはもっと凝った構造化されたランタイムアサーション。一体どこが似てるんだ?全然別物だよ。
どちらも頭文字がCで、2音節で、規格に入るのに苦労した(している)。注意して見てないと混同しやすいよね。
まったくその通り!(HNの別スレでも同じ指摘がある)
で、この人はヒーローなのか悪役なのか?それもconcepts次第ってこと?
conceptsじゃなくて、contractsね。
こっちの記事のほうが入門にはいいと思う。cppreferenceはそれ自体が技術的すぎることが多いからね。でもより大きな問題は、contractsが実際にどう動くのかを示す十分に良い「見せ方」を見つけるのに自分は何度も検索しないといけなかったってことで、つまりその提唱者たちはまだ人々の心をつかみきれていない、というのが今回の件につながってるんだと思う。
自分はC++の人間じゃないけど、それはHoare logicっぽくてかなりかっこいいと思う。
TIOBEなんて意味のない指標だよ。とはいえ、今でもRustより多くの新規C++コードが書かれているのは事実。C++はいずれレガシーになると思うけど、まだそこには至ってないし、そうなったとしてもC++を書かなくなるまでには少なくとも数十年はかかるはず。
「GoかRust以外のほぼ全ての本番言語」の話だとしても、それらすら怪しい。RustはC++で書かれたLLVMに依存してるし、Goもプラットフォームによってはlibcを必要とする。
この話題の背景と論点
C++の規格化はISOの作業部会WG21が担い、最終草案(DIS: Draft International Standard)は加盟各国の投票で承認されるのが通例で、今回のような否決は初めてとされる。争点になったcontractsは、関数の事前条件・事後条件をassertより柔軟に書けるようにする機能で、スレッドでも「concepts」(テンプレートを制約するコンパイル時の仕組み)と名前や発音が似ているせいで混同する投稿が複数見られた。両者はコンパイル時と実行時という別の仕組みであり、読む際に区別しておくと理解しやすい。また否決によって、contracts以外にreflectionやstd::execution、library hardeningといった注目度の高い機能も同じ草案に含まれていたために足止めされている点は、スレッドでは言及されているが見落とされやすい事実だ。否決を「信頼の崩壊」と見るか「二段階承認という制度が正しく機能した結果」と見るかの評価の違いは、contracts自体の評価以上に、C++の標準化プロセスへの信頼度の違いを反映していると言える。
※本記事は海外掲示板 Hacker News のスレッド「C++26 Disapproved」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
まだコメントはありません。