C++の設計者でオリジナル版実装者のBjarne Stroustrup氏が先日，C++17の設計目標と実現される新機能に関する“議論提起”を目的とした，ドラフト文書の配布を行った。C++17には３つの設計目標がある，と氏は言う。
- 大規模で信頼性の高いソフトウェア開発サポートの強化。
- 並行処理のための高レベルなモデルのサポート提供。
- 中核言語の簡略化。
これらの目標それぞれに対してStroustrup氏は，C++17でそれを実現するための新機能をリストアップしている。予想される機能の中で氏が望ましいと考えているのは，次のようなものだ。
- モジュール。局所性とコンパイル時間を改善する。
- 契約(contract)。仕様の明示性の向上。
- タイプセーフな共用体と，おそらくは関数プログラミングのスタイルに基づくパターンマッチング。
- コンセプト(concept)。
- レンジ(range)。
- 呼び出し構文の統一。仕様定義とテンプレートライブラリの利用を簡略化する。
- コルーチン。すなわち，再開可能な関数。
- SIMDベクタ。現代的なハードウェア機能の活用。
その一方でStroustrup氏は，C++17がどのようなものになるのか，“言語の機能や標準ライブラリのコンポーネントの数”でその詳細を判断するという，誤りを犯さないように警告する。重要なのはC++14等とは対照的に，C++17が“メジャーリリース”になるという点を理解することだ。従って，ユーザの言語利用に大きな影響を与えるという意味において，少なくとも“２ないし３の主要な機能”を含んで然るべきである。コンセプトやモジュール，レンジなどは，その例だ。
興味深いことに，氏の文書も，C++17がどのようなものになるかを明確にしようとしている。望ましくない機能として，氏は，次のようなものを具体的に挙げる。
- C++を根本的に異なる言語に変えたり，あるいは高レベルのサブ言語を別に提供すること。
- “他のすべての言語”への対抗や，新しい“パラダイム”をサポートする目的で，C++に新機能を加えること。
- “最も要求の厳しいタスクであるシステムプログラミング”を前提に，言語を複雑化したり，言語の能力を阻害したりすること。
Stroustrup氏に話を聞いた。
C++17の機能一覧について，どのように思われますか？優先順位リストのようなものはあるのでしょうか？
コンセプトとしては，私たちが考えるジェネリックプログラミングを変えようとしています。ジェネリックプログラミングを，今よりももっと中心に据えようとしているのです。それと同時に，エラーメッセージの内容に対する不満 - これは理解できますが - にも対処しようとしています。十分な効果を得るためには，このコンセプトを標準ライブラリに取り入れることが必要です。
モジュールは，コンパイル時間を劇的に改善し，マクロ乱用の悪影響を制限することによって，C++をさらによいツールにしてくれると期待しています。
高レベルの並行モデルは，コンカレントなコード記述の難しさを大幅に改善してくれます。完成したコードの実行速度も，低レベルなスレッド・アンド・ロックで記述されたコードより速くなるでしょう。
コードをシンプルにすることで品質を改善するのですから，これらの機能は理想的なものです。
過去数年間の委員会での活動と，C++17のために実施される今後の作業によって，C++は，これまで議論の的となってきた大きな制限のいくつかを克服しようとしています。このことは，“委員会による設計では実質的な進展をもたらすことはできない”とされていた，これまでの根強い考え方を反証するものだとも言えます。委員会が行ってきた活動について，どのようにお考えですか？成功の秘訣といったものがあるならば，どのようなものを採用したいと思いますか？
委員会による設計に問題があることは否定できません。100人(会議に参加せず議論に加わっている人たちも含めれば300人)という人々が集まって，堅牢で一貫性のあるものを新たに作り上げるというのは，極めて難しい作業なのです。
それがうまくいっているというのは驚きですが，もっとうまくできたはずだ，という例もあります。委員会での作業はフラストレーション以外の何ものでもありませんが，このスケールの作業を個人が単独で管理するというのは，確かに不可能です。ですからこれは，個人か委員会かという問題ではなく，必然としての委員会をどのように運営するか，ということなのです。今日，世界的に重要なもので，個人が援助なく作り上げたというものはほとんどありません。
C++17は，比較的低レベル(言語のセマンティクスが非常に詳細なコントロールを可能にするものである，という意味において)の，マルチパラダイムで難しい言語であるという，C++の性格を追認するものになっています。その一方で，より“簡単に”使える言語にするという目標が，委員会の作業の主なモチベーションのひとつになっています。C++をもっと気軽に使える言語にするために，委員会の標榜する原理のようなものはあるのでしょうか？
言語のレベルというのは，もはや理念としては通用しません。ハードウェアを直接操作するための卓越した能力と，必要であれば抽象化レベルを向上可能な抽象化メカニズムを両立した言語として，C++を理解してほしいと思います。ハードウェアに密接に関係するプログラミングは，多くの重要なタスクで必要なものですが，あまり楽しくはありません。C++はオーバーヘッドのない抽象化を可能にすることで，コストを加えることなく，ハードウェアから私たちを隔離してくれるのです。ただし，ここで“オーバーヘッドのない抽象化(zero-overhead abstraction)”というのは，手作業で作成したコードに対して1バイトも，1サイクルも無駄にしていない，という意味ではありません。関数コール(特に間接的な関数呼び出し)によるオーバーヘッドは，必要以上に意識されることが少なくありません。ハードウェアへのアクセスと抽象化の両方を提供することがC++の基本であり，それを効率的に行うことで，他の言語との差別化が図られているのです。
これはもはや，“マルチパラダイム”というものではありません。その呼び方は，言語の持つ機能をフルに使うのではなく，多くの人たちに対して，どれかひとつの“パラダイム”を選択するように求めるものだからです。残念ながら，それに代わるよいキャッチフレーズは見つかっていませんが。
委員会に何らかの理念があったとは，とても思えません。私たちは多様なバックグラウンドを持った多くの個人であり，視点もさまざまです。ですが，先に述べたようなC++の説明に対しては，ほとんどが同意してくれるでしょう。それはC++の基本であり，妥協することのできない部分です。互換性に対して厳しい見方をしなければならないことも，同意を得られる点です。C++コミュニティは進歩を望んでいますが，そのプロセスにおいて，彼らの何十億行というコードが損なわれるというのは，まったくもって認めがたい事態なのです。どのような改善が最も有意義なものか，合理的なタイムスケールで実現可能なのはどれか，それらを言語仕様ないし標準ライブラリとしてどう実現するか，といったことの詳細が重要です。大勢のグループで同意を得るのは難しいことですが，合意は不可欠です。私が今回の文書を書いて，それを次のミーティングで議論しようとしているのは，そのような理由によるものです。
私はこれまで，C++とその標準化に多くの時間を割いてきました。それがコンピュータ，半導体，輸送，通信，金融，製造，航空宇宙など，多くの産業において重要な部分を占めているからです。非常に重要なシステムやガジェットの中を見れば，そこにC++が導入されていることに気付くでしょう。そのような事実に加えて，微力ながらも科学の発展を支援できるという意識が，私のモチベーションになっています。C++は，重要な成果物の構築に使用するツールであるべきです。
Stroustrup氏の案は以前にredditやHacker News，The Registerに公開され，多くのコメントが寄せられた記事に対するフォローアップである。