C++17の時代 - Herb Sutter氏に聞く

ISO C++委員会は先月、2017年4月に作業の完了していたC++17標準を正式に承認した。新C++標準についてはInfoQでもこれまでに何回か取り上げ、承認された主な新機能とコンパイラの実装状況を詳しく説明している。今回我々は、長年にわたってC++委員会の活動に携わり、委員長も務めるHerb Sutter氏と話す機会を得ることができた。

InfoQ: C++17には、新機能が数多く含まれていて大変そうだ、という第一印象があります。今回の新標準の主な特徴は何でしょう？開発者に最も喜ばれそうなC++17の機能は何だと思いますか？

Herb Sutter: 私がC++17で重視したのは、日々の開発作業を簡単にしてくれる機能です。

C++11が登場した時、数多くの新機能の中には大規模で派手なものもありましたが、実際にインパクトがあったのは“毎日使う小さな機能” – レンジベースのforループ、auto、スマートポインタ、ラムダ、クラスメンバの初期化といったものでした。これらはコードをよりクリーンかつ安全にするために、私たちが日々目にしたり、使ったりするものです。

今回のC++17でも、一部からは並行STLのような“大きな”機能に期待が寄せられいました。しかし私は、毎日目にしてその恩恵に預かるのは、例えば構造化束縛(structured binding、for (auto [key,value] : my_map) {…}のような記述)やクラステンプレート引数の推論(pair<int, double>{1, 2.0};をpair p{1, 2.0}; のように記述)、forループで既に可能なスコープ内変数の初期化がifやswitchでも可能になったことなどだと思っています – これらの機能は、私たちがコードを書く上で必要なセレモニーを少なくして、コードの記述やメンテナンスをより簡単なものにしてくれます。標準ライブラリでは、std::string_viewとstd::optionalが新たなキーである“語彙型(vocabulary type)”として、関数パラメータや戻り値に広く利用されるようになると思います。std::string_viewはstring型のテンプレート化を置き換えることができます。std::variantとstd::anyも一般的な型として、クラスメンバや関数本体の内部で頻繁に目にするようになるでしょう。

小さな機能、特に簡素化に焦点を当てたものほど、長く利用されるようになるものです。

InfoQ: 最も待ち望まれていた機能であるコンセプト(concept)は、C++17では採用されませんでした。延期された理由についてコメントを頂けますか？

Sutter: 単にタイミングの問題です – 成熟のための時間が必要なのです。

コンセプト機能はすべての人が望んでいますし、着実に進歩しています。私たちが技術仕様書(TS/Technical Specification)と“ベータブランチ”を公開してから、C++17のフィーチャフリーズまでは1年も経っていません。ですから委員会では、締め切り間際で標準に押し込むよりも、TSからもっと経験を得るべきだという意見が大半を占めていました。TS/ベータで機能を公開することで、標準として仕様が固まってしまう前に、フィードバックを取得して変更を加えることが可能になります(そうあるべきです)。機能がC++国際標準(IS/International Standard)として公開されてしまえば、私たちの在任中は固定されて、互換性を損なう必要のある修正を行なうことはほぼ不可能になります。

コンセプトはすでに現在、C++20のドラフトに含まれています。今年夏に開催されたC++20の定期会議では、C++17以降のC++に追加される最初の大きな機能として取り上げられました。興味深いのは、TSでの経験を基にした改善がすでにいくつか含まれていることです – C++17に無理に押し込んでいたら、このような変更は不可能か、あるいは非常に困難だったはずです。

InfoQ: C++20ではどのような領域が重視されるのでしょう？

Sutter: 公開済みのTSを見て頂ければ、今後のC++の主要な機能を理解して頂けます。最新のリストはisocpp.org/std/statusで公開中です。一般論としては、次期標準のカットオフの1年以上前に公開されたTS、C++20の場合ならば2018年始めまでに公開されるTSについては、次期標準のマテリアルとして候補に含まれる可能性が高くなります。注意して頂きたいのは、TSが変更なしで採用されることはない、という点です – これは同時に、規模の大きな、あるいは実験的な機能において、最初にTSを実施することの有意性の証明でもあります。

すでに公開済みのTSの内、C++17で採用されなかったのは主に次のものです。

Concepts TS: “簡潔な構文(terse syntax)”(void f(MyConcept param) {…}のような記述)を除けば、すべて採用済みです。委員会としては、いくつかの技術的な懸念事項に対処する改善が実施されれば、その後は構文に関する検討を行なうという意思を固めています。次回の会議では、C++20のドラフトにその形を取り入れることができると思います。

Concurrency TS: これは実際には機能グループで、個別にチェリーピックされることになるでしょう。アトミックなスマートポインタとラッチについては、採用される可能性が高そうです。future<>拡張は、現在は未提出のコンカレントエグゼキュータ(concurrent executor)提案に依存しているため、そちらが実施されるのを待つことになるでしょう。

Library Fundamentals 2: これもライブラリ機能のグループで、機能単位でC++20ドラフトにマージされると思われます。

Ranges TS, Coroutines TS, Networking TS: これらは最終承認を受けて近々公開される予定なので、来年にはC++20ドラフトに統合される可能性が高い機能です。

ただし、これらの機能がC++20に含まれると言っているのではありません。あくまでも有力な候補のリストです。その他の大きな機能でも、静的リフレクション(static refrection)など遠い将来ではないものは、１つか２つはC++20に取り込まれる可能性がないとは言えません。しかし実際にそうなるかどうかは、それらの提案が今後6～12ヶ月でどこまで完成度を上げるかにかかっています。当然ですが、ここで挙げたものがC++20で予定されているすべての機能ではありません – 標準には必ず、前もってTSを通過する必要のないような、無数の小さな改良点が含まれているものです。

InfoQ: RustやSwiftやGoといった新しい言語で、興味深いものや、あるいはインスピレーションを得るようなものはありますか？

Sutter: もちろんです。他の言語で行われている探求や実験には常に注目しています。新たな言語の登場や興隆は、この業界の健全性を示す重要なサインであると私は思っています。定常的にアイデアを提供し合うことによって、すべての人々のエコシステムが改善されるのです。

特にSwiftは、現行の主流言語(Objective-C)を明確に置き換えようという観点から、素晴らしい試みです。新しい言語の開発と普及を進めている企業が、既存言語を使用している主要企業であると同時に、その言語が主流となっている２つのOSプラットフォーム所有企業であるというのは、新言語にとっては理想に近い状況です。これはおそらく、その新言語をプロモートする企業にとって、他言語の市場や開発ベースを大々的に獲得する(あるいは代替する)上で、最も大きな影響力となるでしょう。どのような進展を見せるか興味深く、また参考にもなります。

InfoQ: あなたはC++に関して重要な著書を多数お持ちですが、現在執筆中の新たな本はありますか？あるいはもっと広く、現在は何に注目していますか？

Sutter: 本や記事を書いているのは、書くことが好きだということ、そして自分自身の勉強のためです。新しいことを分かち合うのが楽しいだけでなく、他の人に教えるためには、自分自身がそれを深く理解する必要があります。人に何かを説明することで、自分の理解が完全であると確認すること以上のものは他にありません。

最近はC++の新機能を勉強するよりも、定義することの方が多くなっています。ですから今は本や記事は書いていませんが、近いうちにQ&A形式のブログ記事をいくつか書くつもりです。現在の執筆作業は、ほぼすべてが標準提案書とC++コアガイドラインに関するものです。

2年前からは、C++をより強力かつシンプルにする – すなわち、現実のC++コードとプログラムの記述とメンテナンスを簡単にするために、言語をより強力にする – ための方法を探求する、長期的なプロジェクトに重点を置いています。これをずっと続けるつもりです。できることはたくさんあると思うので、いくつか試してみてどれがうまくいくかを確認した上で、一気に標準化へ運びたいと思っています。これまでの作業からは、論文P0515で説明した宇宙船比較演算子(‘<=>’)という小さな機能を提供しています。改善グループではすでに承認されていて、11月に行われる次回のミーティングで表現の標準化に関するレビューを行なう予定です。うまくいけばC++20ドラフトで即採用となるかも知れません。ふたつめはもう少し大きい機能で、まだ試験中の長期的なものですが、P0707で提案したメタクラスに関する作業です。CppCon 2017でのセッションをYouTubeでご覧頂けます。

委員会のより多くのメンバが私に賛同して、言語をシンプルにする作業に加わってくれることを期待しています。小さな機能を独立的に加えていくのは、開発作業としては楽しいのですが、一貫性を欠いた部分的なソリューションが積み重なねられていく危険性もあります。開発者が実際に書くC++コードをシンプルにする余地が残っているということには、大きな意義があると私は思っています。それを実現するためには、言語を幅広く原則的に捉える視点を持ちつつ、部分的な改良を加えていくことが必要だと思います。最初に述べたように、C++11とC++14、おそらくはC++17でもそうですが、それらの中で最も影響力のある機能は、必ずしも“大きな機能”ではなく、むしろ日常的なコードの記述をシンプルにするような小さな機能です。私たちには今、小さなクリーンアップだけでなく、大規模な簡略化によってシンプルさを具体的な目標にする大きなチャンスがあります。これがC++を良い方向に大きく改善してくれるであろうと、慎重ながら楽観的な見方を持っています。Bjarne Stroustrup氏が常々、スクラッチからやり直すことが可能ならば、もっと小規模でシンプルな、文字通りC++の1/10の複雑さの言語をC++から作り出すことができる、と言っているのは有名な話です。もちろん、これをそのまま実行に移すことはできません(Objective-CからSwiftへと同じです)が、漸進的かつ長期的な視野からC++のコードを、そして最終的には言語そのものを、簡素化する手段はあるのではないかと私は考えています。今はまだ道半ばであったとしても、極めて大きな、ドラマティックな改善になるでしょう。

“標準化をもっと早く進められないのか？”という質問を受けることがありますが、およそ450万人のプログラマが使用する言語の改善に時間と労力が必要であることを、C++委員会は認識しています。すべての主要な業界、そして重要なインフラストラクチャからユーザアプリケーション(他言語のコンパイラも多数含まれます)まで、あらゆるソフトウェアの数十億行に及ぶコードへの配慮がこの上なく重要なのです。“素早く行動して破壊せよ(Move fast and break things)”というのは、ここにはまったく当てはまりません。ISO C++での私たちの作業は、この巨大なエコシステムを取り残すのではなく、前に進めることなのです – 追い求めているものがどれほど素晴らしいものであったとしても、それは私たちの進むべき道ではありません。“体系的かつ原則的な改善によって前進する”ということが、私たちの場合には理想的に近いマントラなのです。一般に、２年間にできることは過大評価され、10年で達成可能なことは過小評価されるものだ、という格言を思い出してください。この格言どおりの改善を続けることで、今後10年間でC++はさらに素晴らしいものになる、と私は慎重かつ楽観的に考えています。

Herb Suttrer氏はソフトウェア開発の第一人者で、“Exceptional C++”や“C++ Coding Standars”といった著書を持つ。ISO C++標準委員会の委員長を15年間務めるとともに、MicrosoftではソフトウェアアーキテクトとしてC++/CLI、C++/CX、C++ AMPといったテクノロジのための言語拡張設計を担当している。