このブログの頻繁な読者は、過去 1 年間、私が標準化に適した最新の範囲ライブラリに取り組んできたことを知っています。特に Sean Parent と Andrew Sutton からの優れたアイデアをあちこちから統合し、すぐに利用できるライブラリを作成しました。標準化委員会への提案。今週、アーバナ シャンペーンで開催された C++ 委員会で自分の作品を発表しました。その後の議論は、標準ライブラリの将来に影響を与えます。

Rangesイブニングセッション

私は水曜日の夜、約 60 人の委員会のメンバーに自分のレンジ作業を紹介しました。 とても良かったと報告させていただきます 温かく迎えました。委員会は、私の範囲ライブラリの設計を気に入っており、標準の ASAP でそれを見たいと考えています。グループは、変更が十分に大きいため、TS または 技術仕様 として知られる別のドキュメントで変更する必要があると感じていました。 公式の C++ 標準ではなく。そうすれば、焼き付ける前に潜在的な問題を洗い流すことができます。

範囲が C++17 にないことにがっかりする人もいるかもしれませんが、これは非常に良いことです。ベンダーは TS の迅速な実装と出荷に積極的に取り組んでおり、より迅速に範囲をユーザーの手に渡せる可能性があります。 こちらです。これはまた、TS をターゲットにしているため、遠く離れている可能性があることも意味します。 より野心的。これを C++17 に詰め込もうとした場合、提案を破棄して、非常に小規模で非常に保守的な機能のサブセットを標準化する必要があったでしょう。 TS ルートに進むことで、多くのものを得ることができます より優れたものをより早く世に送り出し、準備が整い次第段階的な更新を出荷します。

Ranges TS の一部が特に見える場合 有望で議論の余地がないため、C++17 に空輸することができます。

標準ライブラリの未来

言語機能としての Concepts Lite の夜明けとともに、次の明らかなステップは、この機能を使用して標準ライブラリを改善することです。範囲の議論の間、誰かのコードを壊さない方法で概念をライブラリに追加することは不可能 (または少なくとも非常に望ましくない) だろうということは、一般的に受け入れられているように見えました。委員会は嫌い 作業コードを壊します。 1 つの可能性は、ライブラリの新しいバージョンを古いバージョンと一緒に出荷することです。その後、ユーザーは自由に移行できます。その可能性は公然と議論され、多くの人がうなずきました.

その場合 Concepts Lite を活用するだけでなく、範囲をサポートし、統一性と表現力を高め、使いやすさと安全性を高め、長年の問題を修正するために、標準ライブラリを自由に変更できます。最終的に何を手に入れてもたくさん見えるだろう 現在の標準ライブラリと同様に、もちろん既存のコードは引き続き機能します。

これは私の意見であることを強調させてください 部屋の一般的な感じ。委員会はこれについて投票していません。 とは 明らかなのは、Concepts Lite を使用し、私の range-v3 ライブラリによく似た STL のバージョンで作業が開始され、このバージョンは そうではない ことです。 完全な下位互換性を優先します。その作業は技術仕様に入り、ベンダーは std::experimental で出荷を開始します。 プレスに当たるとすぐに名前空間。これ以上興奮することはありません!

私の意見と将来の可能性を明確にするために編集