コナ:旅行レポート

私は幸運にも 3 回目の wg21 委員会に参加することができました。今回は 13000 キロ離れたハワイのコナで開催されました。

伝統と同様に、ブライスと他の人々は Reddit でかなり詳細な旅行レポートを書いているので、ぜひチェックしてみてください。しかし、私の経験と重要だと思ういくつかの提案の詳細を読みたい場合は、読み進めてください (あなたの時間は限られているため、他のブログ投稿を読む時間が少なくなります)。

少数の活発なスタディ グループ、2 つのインキュベーター グループ、Evolution、Library Evolution、Core Wording Group、Library Wording Group があるため、同時に進行している 7 つほどの部屋で起こったことすべてを詳しく追跡することは不可能です。私が強い意見を持っているいくつかの提案について、私が非常に中立だと思う機能についての議論に参加しました。

それが人生です。

また、ほとんどのトピックについて、私は愚かすぎて十分な情報を得ることができないという理由で、意見を持たない権利を留保します。

そして、委員会は決して減速していません。Kona の前のメーリング リストには、驚異的な 177 の論文があります。これまでに見たことのない 144 の論文を含みます。この会議は、C+20 の機能凍結でもありました。つまり、会議終了までに進化グループによって承認されなかった機能は C++20 に追加されません。少なくとも、それが理論です。

この会議は歴史的なものであると説明されており、実際、しばらくの間作業を行ってきた多くの主要な機能と、多くの小さな生活の質の改善を承認しました. C++20 は、C++11 以来の最大のリリースになる準備ができています。

この会議で実際に追加された機能の数は比較的少なかったですが、多くの論文が文言グループを通過するのを待っており、ケルンで受理されるはずです.

コルーチン

コルーチンは非常に強力なコンセンサスでマージされました。これは素晴らしいことだと思います。C++ の開発を詳しく追跡すると、その設計が過去 1 年間で大幅に変更されていないことに気付くでしょうが、サンディエゴではそれらをマージするというコンセンサスはありませんでした。またはラッパースウィル。では、なぜ今なのか?

コルーチン TS の競合点の 1 つは、タイプが消去されたコルーチン フレームを常にヒープ割り当てし、フレームが呼び出し元のコンテキストより長く存続しない場合にこれらの割り当てを消滅させるために、優れた最適化手法に依存していることです。

コア コルーチンの提案では、コルーチン フレームの確定的なスタック割り当てが提供されました。

スタックに割り当てられたコルーチン フレームの問題は、ブラック マジックなしでは最適化できないことです。そのブラック マジックには、Deferred レイアウトという名前が付けられました。コルーチン フレーム。次に、スタックに割り当てられたコルーチンを最適化します。ただし、これらの型には constexpr 03 がありません。 これは言語に深刻な影響を及ぼし、さらに重要なことに、コンパイラ ベンダーによって実装が非常に複雑であると見なされています (つまり、そこに到達するには、業界全体で研究開発に数千万ドルかかる可能性があります)。今後 5 年から 10 年で実を結ばない (または実を結ばない) 可能性のある研究分野。延期されたレイアウト型も TU の境界を越えることができないため、何らかの形式の型消去が依然として必要になります。

つまり、TS はすべてのコンパイラに実装され、大きな成功を収めているのに対し、コア コルーチンは非常に長い間実装できないことに人々が気付いたということです。下位互換性のある方法で、コルーチンが将来的に決定論的な割り当てを取得できるようにします。

コルーチンは完璧ではありませんが、圧倒的多数のユースケースに十分対応できることは確かです。また、コルーチンは非常に強力で普遍的に役立つため、ユニコーンを追いかけている間にコミュニティからコルーチンを奪うことは合理的ではないことが明らかになりました.

P1477について議論してほしかったのですが、エボリューションは時間切れのようです。新しいコルーチン型の記述がより快適になるため、C++20 の前にこれについて議論できることを本当に願っています。コルーチン型を記述することは、ほとんどの C++ 開発者がこれまでに行う必要があるとは考えていないことに注意してください。

残念ながら、時間がなくなり、C++20 にはコルーチンの標準ライブラリ サポートが同梱されなくなります。そうでなければ素晴らしい機能であるにもかかわらず、人々に悪い印象を与えるのではないかと心配しています.

そのため、コルーチンを試して使用する場合は cppcoro を使用することをお勧めします。これにより、厄介な詳細が隠され、C++ の将来のバージョンで標準ライブラリが提供するものを期待する良いアイデアが得られます。コルーチンの成功に貢献しました。

次に、キーワードの混乱があります。これはまだ対処することが重要だと思いますが、これは負け戦です. そして 25 既存のコードを壊さずにキーワードとして - 真剣に検討されることを心から願っています!)

全体として、コア コルーチン TS のマージは、過去 5 年間コルーチン (いわゆるゴルーチン) に取り組んできた C++ と Gor Nishanov にとって信じられないほどの成功です。

標準にコルーチンを含めることで、多くの提案や作業への扉が開かれます。たとえば、

  • 使いやすいネットワーキング ライブラリ
  • よく統合されたエグゼキューター
  • Unicode 双方向反復子の適切な実装

モジュール

モジュールも非常に強力なコンセンサスで IS に統合されました。これも、10 年以上にわたって取り組んできた主要な変革機能です。

私は反対票を投じました。理由を説明する必要があるかもしれません!

モジュールは、パラダイム シフトとしてブランド化されています。どちらが間違っているわけではありません。モジュールは、今後数十年で C++ が獲得する最も革新的な機能になる可能性があります。だからこそ、モジュールを正しく理解することが重要なのです。

しかし、ここに問題があります。モジュールは安定していません。ロングショットではありません。静的シンボルのリンケージに関する問題を修正するために、会議中に一夜にして (著者に敬意を表します!) 論文が書かれました。設計は過去 1 年間で (より良い方向に) 大幅に変更されました。

マージされた提案で提案されているように、非レガシー モジュールを使用した経験はまったくありません (ただし、レガシー モジュールには多くの経験があります)。

エコシステム全体に大きな影響を与える機能があれば、モジュールが実際に意図したとおりに機能することを確認し、設計をしばらく成熟させるために時間を割いただろうと思うでしょう.

支持者によると、モジュールはすべてを修正します 、コンポーネント化からODR、コンパイル速度まで、どれだけのコードとビルドシステムが壊れるかは不明です.誰かが言ったように、最初の 33 コードベースのステートメントは非常にコストがかかります。次の 10 年間に痛みと苦しみが予想されます。

批判的に言えば、IS の出荷後にモジュールの動作を意味のある方法で変更することは (ほぼ不可能に近い) 困難です (進化する余地が十分にあるコルーチンとは異なります)。

C++ エコシステムの TR。

Peter Bindels と決定論的なモジュール名のファイルへのマッピングに取り組んでいるときに、IS では (P1427 で表現されているように) モジュールのツール可能性の問題を修正することは決してできないことが明らかになりました。

時差ぼけを手伝って、私はツーリング セッションの日の午前 4 時にいくつかのスライドの下書きを開始しました。その後、数人の SG-15 メンバーと私はプールの近くに座り、Bryce Adelstein Lelbach のおかげで、「C++エコシステムテクニカルレポート」をその日遅くに。

非常に好評でした。

アイデアは、IS とともに、ビルド システムによって駆動されるソース ファイルからマシン コードへのコンパイルの一般的なユース ケースを別の ISO ドキュメントで説明することです。まず、モジュールを実行可能にすることに焦点を当て、後で実行できるようにする予定です。このドキュメントをパッケージ管理に拡張します。このドキュメントは、モジュール化されたコードをさまざまなシナリオやプラットフォームで共有および再利用できるように、すべてのツールとコンパイラに共通のベースラインを提供するためのガイドライン、相互交換フォーマット、およびその他の仕様を提供するよう努めます。

SG-15 は、モジュールが確実に成功するように、IS とほぼ同じ時期にこのドキュメントの最初のバージョンを出荷するのに十分な資料を用意するために最善を尽くしますが、それは難しい注文です。

C++20 には標準ライブラリ モジュールがありません

標準ライブラリは C++20 ではモジュール化されませんが、標準ライブラリ モジュールはレガシー ヘッダー ユニットと見なされるため、46 58 に相当します 64 の間

何らかの理由で、C ヘッダーがレガシー ヘッダー ユニットになるかどうかは実装定義になると判断したため、74 プラットフォームでコンパイルされる可能性があります。かどうか。

標準ライブラリを構成するために使用されるマクロが機能を停止したり、面白くて予期しない方法で壊れたりする可能性があることに気付きましたが、何も停止しませんでした.

モジュールはどの程度壊れていますか?

モジュールはおそらく 90% の完成度です。数回の会議で準備が整うと思います。

言語に関して、この時点での私の主な関心事は 82 です キーワード。これは、モジュールのコンテキストではまったく意味がありません (少なくとも私には)。時間の許す限り、論文で理由を詳しく説明しますが、まだ修正する時間があるとは思えません。たぶんわかります。

TR アプローチがどれだけ成功するかはまだわかりません。現在実装で定義されている動作を指定することに多くのベンダーが同意する必要があるためです。

また、どのモジュールがそうでないかについても、まだ大きな懸念があります.

モジュール コンテキストでの暗黙の前方宣言 (巻き上げ) が真剣に検討されることはなく、言語をクリーンアップする機会 P0997 は打ちのめされ、単一ファイル モジュールのユースケースはほとんど検討されませんでした。モジュール

  • 名前スコープのメカニズム (そうではありません)
  • ライブラリの代替品 (そうではありません)
  • 大幅なコンパイル速度の向上 (一部のユースケースでは多少の改善が見られます)
  • ポータブル (そうではない)
  • シンボルのバージョン管理システム (そうではありません)

委員会の全員がどのモジュールが であるかについて同意しているかどうかはわかりません 、そうであってはなりませんが、少なくとも実装者は皆、モジュールと BMI の実装方法について独自の興味深いひねりを持っています。

  • パブリック インターフェースに含まれるものと含まれないものを正確に指定できます
  • マクロをサンドボックス化する
  • モジュール名は一意である必要があります。これを正しく行うと、パッケージ マネージャーに役立ちます。
  • これらは実際にインターフェース/実装エンティティを具体化します - 正しく行われれば、これはパッケージ マネージャーに役立ちます。
  • 閉まっています
  • 一部の一般的なシナリオでは、コンパイル速度の向上に役立つ場合があります

状況は確かに私がそうするほど悲惨ではありません.申し訳ありませんが、私は少し辛辣です.真実は、プレナリーでのコンセンサスは十分に強力だったので、おそらく私は間違っていると思います.モジュールは依然として、その作成者による信じられないほどの成果であり、おめでとうございます.

まだ問題を修正する時間はあり、SG-15 は月に 2 回会議を開き、モジュールの採用をできるだけスムーズにするために最善を尽くします。私たちがなりたい場所に向けてグループが小さな一歩を踏み出すのに役立つので、狭くしてください。

私の論文

私が地球の反対側に飛んだ理由の 1 つは、誤ってコナ以前のメールで最も多くの書類を書いてしまったことです。申し訳ありません。

添字式でのコンマ演算子の使用を推奨しない

P1161

論文を書けと言われても、最終的にコアになるとは言いません。言い回しの専門家が各単語、各コンマについて議論していたので、私は自分の論文をライブ編集、生成、アップロードしなければならなかったので、かなりストレスの多い経験でした.私がまだ論文を修正しようとしていたので、要求されたすべての変更を追跡することは決定的に困難でした.

しかし、紛らわしい表現はほとんど実装できず、結局のところ、その表現は WG21 の作業の唯一の成果物であるため、必要なプロセスです。>

さて、mdspan と線形代数の行列がそれを利用できるように、C++23 の時間枠でその構文をどのように再利用できるかという問題が残っています。

source_location

P1208

99 ほとんどが Robert Douglas の作業ですが、Library Fundamentals からなんとか引き抜くことができました。次の会議で C++20 WD にマージされることを期待しています.LWG は、公式の延期後に文言の最初のレビューを行いました会議の内容 (これは中心部ほどではありませんでした) であり、ポスト メーリングで文言のほぼ最終版をアップロードします。

104 119 のインターフェイスを統一しようとしているため、C++20 の公開前に API が若干変更される可能性があります。 、 121 そして134

シングルパス イテレータの可動性

P1207

このホワイト ペーパーでは、非フォワード イテレータのコピー可能性要件に対処することを提案しています。これは小さな変更であり、かなり大きな影響があります。これについては、別のブログ投稿を行う必要があります。論文を読むことをお勧めします。可能な限り設計してください。

まだ完全な文言を提供する必要がありますが、LEWG はデザインを承認しており、すべてがうまくいけば 20 年に入るはずです。私がデザインを形作り、簡素化するのを手伝ってくれた人々 - 最初の繰り返しはかなりひどいものでした.

基本的な考え方は、非前方反復子が繰り返し処理に使用されるオブジェクトは規則的ではないため、非前方反復子も規則性を必要としないということです。実際、シングルパスの概念とコピー不可。

実際には、この変更により、より安全に使用でき、簡単に教えることができる非前方反復子の作成が可能になります。

この変更を現在行っている理由の 1 つは、標準的な概念は決して変更できないということです。まったく 概念の緩和と要件の追加の両方が API の中断を表しているためです。

新しい範囲の概念は、反復子の要件をより明確に定義するためのユニークな機会を与えてくれました。私たちはそれを採用しました.過去数か月にわたって言葉遣いを繰り返し、できればケルンの前に価値のある標準的なものを LWG に提示する必要があります.選択肢がありますよね?

すべてを適切に正しく取得することが重要であるため、C++20 の出荷前に他にもいくつかの調整が行われる可能性があります .

範囲::to

P1206

いいえ、範囲 2 は提案していません。

P1206 はもともと「コンテナーの範囲コンストラクター」と呼ばれていましたが、このアプローチは 140 によって打ち負かされました s.そこで、設計図に戻って、既存の 154 にかなり近いデザインで戻ってきました。 の 161

172 関数とパイプ可能オブジェクトの両方として機能し、範囲からコンテナーを構築できます (それが別のコンテナーであるかビューであるかに関係なく)。標準コンテナー、連想コンテナー、アロケーターなどの追加パラメーターをサポートし、コンテナーの値の型を推測できます。タイプしてください。

std::list<int> l;
std::map<int, int> m;
// copy a list to a vector of the same type
auto a = ranges::to<std::vector<int>>(l);
//Specify an allocator
auto b = ranges::to<std::vector<int, Alloc>(l, alloc);
// copy a list to a vector of the same type, deducing value_type
auto c = ranges::to<std::vector>(l);
// copy to a container of types ConvertibleTo
auto d = ranges::to<std::vector<long>>(l);
//Supports converting associative container to sequence containers
auto f = ranges::to<vector<std::pair<const int, int>>>(m);
//Supports converting sequence containers to associative ones
auto g = f | ranges::to<map>();
//Pipe syntaxe
auto g = l | ranges::view::take(42) | ranges::to<std::vector>();
//Pipe syntax with allocator
auto h = l | ranges::view::take(42) | ranges::to<std::vector>(alloc);
//The pipe syntax also support specifying the type and conversions
auto i = l | ranges::view::take(42) | ranges::to<std::vector<long>>();
//Pathenthesis are optional
auto j = l | ranges::view::take(42) | ranges::to<std::vector>;
//and types
auto k = l | ranges::view::take(42) | ranges::to<std::vector<long>>;

この機能は LEWG によって受け入れられました。LWG が言葉遣いをレビューする時間があれば、C++20 に存在するはずです。これは私がまだ書いていませんが、ケルンでです。パラテスをオプションにします。マイナーな実装と設計の変更がその週に行われたため、ポスト メーリング リストで新しい改訂を期待してください。

この関数は非常に便利だと思います - 特に (怠惰な) ビューをメモリに貼り付けるのに。

すべてのものを概念化する

187 によって制約される一般化された範囲ベースのコンストラクターを提案しました 194 の両方に および 204 どちらも受け入れられました - いつものように文言のレビューが保留中です。これにより、ビューと 213 からスパンを構築できます たとえば、226 から または 236 -これは常に 240 の意図でした .

もっとピーマン 🌶️

私はまだひどいフランス語訛りを持っています.

とにかく。

移動専用ビュー

P1456

Casey Carter は移動のみのビューに関する論文を提案しましたが、これは多かれ少なかれ移動のみのイテレータと同じ理由で受け入れられました。 移動のみの述語をサポートできます。

すべてを見る

P1035

STL の範囲をまとめることは、これらの論文の共通のテーマであることにお気付きでしょう。P1035 は、Christopher Di Bella によって作成され、その記事の最大の部分です。

  • istream_view (入力ストリームのビュー)
  • take_while (述語に一致する範囲の最初の要素を表示)
  • ドロップ (n 番目の最初の要素をスキップして、範囲の要素を表示します)
  • drop_while (範囲の要素を表示し、述語に一致する最初の要素をスキップします)
  • キー (一連のペアの最初の要素を表示)
  • 値 (一連のペアの 2 番目の要素を表示)
  • 要素 (一連のタプルの n 番目の要素を表示)

Christopher は親切にも彼の論文に最後の 3 つのビューを追加することを許可してくれましたが、最終的には彼がほとんどの文言作業を行うことになりました.Chris に感謝します!

269 ペアとタプルを慎重に変更する必要があるため、カットしませんでした。 270 提案されていませんが、 289 の同じ変更が必要です 292 として .これらの非常に便利なビューが C++23 で提供されることを期待しています。

クロノとテキスト形式の統合

P1361

クロノとテキストフォーマットの統合 302 の作成者である Victor Zverovich と Howard E. Hinnant によって作成されました。 と 315 329 は、C++ で日付または時刻をフォーマットする唯一の方法です。一貫性が増し、重複が回避されるため、このペーパーが気に入っています。よりシンプルで無駄のない API!

アウト ポーター

P1132

330 JeanHeyd Meneide によって作成された は、341 を期待する C API を安全に処理するためのユーティリティです。 これは、これまで C API を扱わなければならなかったすべての人にとって有用です。これが、この会議で LEWG が見た最後の論文だったと思います。

C API、353 を扱うためのもう 1 つの便利なポインター型 - Isabella Muertedid によって提案され、C++20 には採用されませんが、C++23 では採用されるべきです

自動参加割り込み可能なスレッド

P0660

362 停止を要求でき、破棄時に自動的に参加するスレッドです。とても便利です。

volatile の廃止

P1152

JF Bastien のおかげで、378 を取り除くためのいくつかの措置を講じています。 C++20 には含まれないはずの keyword.P1382 は、volatile の有用な使用例の適切な代替手段を提供します。

スパンのサイズ タイプ

span のサイズ型を size_t と一致させ、非メンバーの 381 を提供しました そのようなことを気にする人のために、署名されたサイズを返す関数。これで、その話はやめましょう。

🕴️ユニコード🕴️

ctre

395 に基づく提案を初めて見ました 、その作者であるHana Dusíkováによって提示されました.CTREのようなものが標準に含まれる可能性に私たちは皆興奮していると思います.しかし、Hanaに408について説明する必要がありました. 修復できないほど壊れているため、Unicode サポートを追加することはできません。また、正規表現エンジンを標準に追加する負担を考慮して、ctre を 412 .

しかし、問題は、Regex が Unicode の最後のボスであり、Unicode Regex TR が非常に大規模であるため、事実上誰もそれを完全に実装していないということです.SG-16 は、しばらくの間、その野獣に取り組む準備ができていない可能性があります.

それでも、私たちは 421 が本当に必要です Unicode および UTS#18 との前方互換性を確保する必要があります。そのハードルは、ctre が標準化されていない prce の構文に基づいていることです。幸いなことに、ECMAScript 2018
Unicode のレベル 1 サポートを指定するので、C++ はうまくいけばその作業に依存できるため、文言を簡素化できます -439 ECMAScript 仕様の古いバージョンから派生したものです。

要するに、Hana は手がいっぱいになりますが、事前に計画している限り、Unicode サポートを段階的に追加することができます。

トランスコーディング

また、トランスコーディング API の要件を説明する提案についても話し合いました。今後の会議で、この分野に関するより多くの文書が得られることを期待しています.

明るい未来

委員会のメンバーとして、私たちは先頭に立って生きていきます。私たちのほとんどが C++17 以前で立ち往生しており、しばらくの間はそうなるでしょう.C++20 への準拠にはかなりの時間がかかります. C++23 および 26 で期待されるいくつかの提案があります

  • コルーチンとモジュールのライブラリ サポート
  • 決定論的例外
  • 値ベースの静的反射
  • パターンマッチング
  • 445
  • 457467
  • [477 ] (https://wg21.link/p0009)
  • テキストのコード変換と Unicode のサポート
  • 執行者
  • より一般的に言えば、非同期、同時、並列、および異種計算のためのより多くの機能
  • その他の範囲 (非同期範囲、アクション)
  • より良い乱数生成機能
  • 488
  • より優れた自立型ライブラリ
  • スコープ、サニタイズされたマクロ
  • もっとたくさん!

LEWGI と EWGI グループは信じられないほどの成功を収めており、委員会の帯域幅を大幅に拡大したようです.Bryce と JF はそれから信じられないほどの仕事をしています.研究グループも非常に活発であり、私は SG の専門知識に感銘を受け続けています- 16名(テキスト研究会)

ケルンでお会いしましょう

コナにいる以外の選択肢を与えてくれた人々、特にブライスと C++ 財団にとても感謝しています。ハワイは素晴らしい場所であり、永遠にそこにとどまることを想像するのは簡単です。変化に富んだ息をのむような風景、愛してはいけないものは何ですか?

ただし、仕事に戻って (私は日雇いの仕事をしています)、書類を作成する時間です。次の会議に向けて 6R0 の書類を作成する必要があると主張する todo リストがあります。なぜそんなことをしているのか、いまだにわかりません。

WG21は再び会合を開きます。次の開催地は、ケルン、ベルファスト、プラハ、ブルガリア、ニューヨーク 🗽 (暫定) で、ちょうど 2 年後にコナで開催されます。

最も重要なことは、すべての素晴らしい委員会メンバーに会えたことです。(特に?) 私たちが意見を異にする人たちも含めて。