Douglas Gregor、フランクフルト会議について語る

What Happened in Frankfurt? « C++Next

これは全C++0xプログラマが読むべきだと思う。悲しい話だ。

フランクフルトで何があったのか？

C++0xの発展に興味のある人は、もうニュースを聞いただろうと思う。ISO C++委員会は、2009年7月のフランクフルト会議で、C++0xのドラフトから、Conceptを外すことを、投票で決めた。Conceptは、C++0xの重要な機能で、その削除は、かなりショックを与えたことだろう。ここでは、私はConceptをC++0xに入れるにあたってなされた努力と、結果的に失敗した理由を、語ろうと思う。

Conceptの歴史

C++プログラマは、常に、もっとマシにtemplateを使いたいと考えていた。契約的（原語：constraints）なC++のtemplateは、少なくとも、Bjarne StroustrupのThe Design and Evolution of C++（15.4を参照のこと）（訳注：邦題、C++の設計と進化）の頃からあった。Jeremy Siek と Andrew Lumsdaine はこの契約的なチェック機構を、conceptへと拡張し、根本的には、templateの定義を型チェックするように振る舞うことを示した。（Siek2000）　2003年、Bjarne StroustrupとGabriel Dos Reisは、一連の提案書を書き（N1510、N1522、N1536）、C++言語において、conceptがどのように表現できるかということを、考察した。

私自身のconceptへの関わりは、2005年の1月に、Concepts for C++0xを共著したことから始まった。これは、インディアナ提案と呼ばれているものだ。そのすぐ後に、Bjarne Stroustrup と Gabriel Dos Reis は、A Concept Design (Rev. 1)という提案を著わした。これは、テキサス提案と呼ばれることになった。Conceptが始めてC++委員会で議論されたのは、2005年の4月のノルウェイで行われたリレハンメル会議においてだった。インディアナ提案とテキサス提案は、明らかに、設計思想を異にする物であった。もちろん、お互いの主張は色々あったが、最も根本的な違いは、如何にして、conceptにおいて、データとしての型にmatchingさせるかということであった。テキサス提案は、すべてにおいて、暗黙的な（自動的な）matching（例えば、現行規格のauto conceptのようなもの）を好んだ。インディアナ提案は、すべてにおいて、明示的に妥当性を示されており、remapping可能（例えば、現行規格のconcept mapのようなもの）であるものを好んだ。

リレハンメル後、私は六ヶ月かけて、ConceptGCCを実装した。最初にして唯一の、conceptを実装している実験的なコンパイラだ。このコンパイラは実際の実装を提供することを意図していた。（訳注：この一文、原文では、proof-of-conceptとかけているらしい）　ConceptGCCでの経験は、インディアナ提案をすばらしいほどに改良できた。私は2005年10月の会議で、ConceptGCCを披露した。委員会の反応は、おおむね良好だった。しかし、一部の委員は、二つの提案が著しくかけ離れていくのを危惧した。（訳注：インディアナ提案とテキサス提案の）著者達は、協力して、統合した提案を書き始めた。我々は多くの会議をして、細部を洗い出し、最終的に、最初の統合された提案を、2006年6月に発表した。同時に、ConceptGCCの標準ライブラリの開発が進められ、我々は、最初の提案書である、標準ライブラリにおけるConcept（N2036-N2041を参照されたし）を書き上げた。

我々は委員会外で何度か会議を行った。会議毎に、さらなる議論と、それに伴う提案書の変更がなされた。最大の変更は、or constraintsの削減、scoped concept mapの導入、forwarding functionの省略、だ。またこの時点で、私は最初のドラフトである、conceptの規格書における文面を書き上げた。これは後に、言語とライブラリの両方で、幾多も改訂されていくことになる。

2008年9月のサンフランシスコ会議にて、conceptはついに、ワーキングペーパーに取り込まれ、最初のC++0x candidate draft (CD1)に入った。つまり、C++0xのリリース候補のドラフトに、第14版にして、取り込まれたのだ。これは、コア言語とかなりの分量のC++0x標準ライブラリを占める

フランクフルトまで

サンフランシスコ会議から6,7ヶ月たち、標準規格と標準ライブラリの文面に、様々な改良が加えられていった。フランクフルト会議が近づくにつれて、ある二つの問題が持ち上がった。実装経験に対する憂慮と、統合されたconcept規格に対する思想の相違である。

実装経験への憂慮というのは、ConceptGCCの不完全さである。例えば、コンパイルのパフォーマンスが低いことや、高度な機能に欠けていること（scoped concept map、associated template）だ。委員会の委員達は、conceptベースの標準ライブラリを評価するのに、製品レベルの品質を持つ実装が無いという現状では、言語とライブラリのconcept規格には、未だ多くの欠陥が残っているであろうことを憂慮した。これらの欠陥は、良くて、C++0x規格の発行を更に遅らせるし、最悪の場合、欠陥だらけの規格を世に出してしまうことになる。

同時に、conceptに関する、多数の、白熱した議論が委員会のメーリングリストでなされていた。多くは、現行規格の使いにくさの問題である。例えば、場合によっては、ライブラリのconstrained templateの要求を満たすためだけに、ユーザーは空っぽのconcept mapを書かなければならない。ユーザーはそのようなconcept mapを、文法上のゴミであると看過するだろう。議論はBjarne Stroustrupのペーパー、Simplifying the use of conceptsに集約された。これらの設計に対する不安は、インディアナとテキサスの思想が、今以て、いかに大きな隔たりであったかを物語っている。あげく、Stroustrup博士のペーパーは、所謂、明示的なconceptを削減しようとまで提案していた。これは2005年からの、conceptの根本的な問題であり、そもそもの初めからの問題だったのに。

フランクフルトにての投票

C++委員会は、フランクフルト会議の初めから、およそ半日かけて、conceptの境遇について議論した。Stroustrup博士は、次の三つの選択について、投票をさせた。

1. C++0xの現行規格のConceptを維持する。
2. ”Simplifying the use of concepts”の提案を受け入れて、C++0xにconceptを存続させる。
3. C++0xからconceptを削除する。

疲れ切った委員会の委員達と共に、私は、concept削除に投票した。何故ならば、言語の未来を考えた時、C++0xとconceptにとって最良の選択は、削除することであろうと思ったからだ。

個人的には、現行規格を通すべきだと思っている。これこそが根本的に正しい設計だと信じている。しかしながら、現時点においては、合意が得られていないことは明らかである。広くC++業界に受け入れられる以前に、我々の中でも合意に達しなければならない。就中、実装経験に関する憂慮は、当然のことである。それだけの故を以て、C++0xからconceptを削除するに足る。

第二の選択である、設計に大幅な変更を加えて、C++0xをconceptと共に発行することは、到底支持できない。開発の、この期に及んで、かかる大きな変更をするのは、極めて危険である。この場合、実装経験がないこと、使用経験がないこと、新設計が動くかどうかを検証する為の技術力が足りない。ConceptGCCですら、十分な実装経験ではないと考える人がいるのだ。変更した設計のまともな実装など、まず出ることはない。そもそも、この問題に関する思想の相違の経緯を考えれば、我々が提案された変更に合意できるわけがない。

他の選択肢もあった。例えば、C++0xを、さらに数年遅らせて、合意を得るだとかだ。しかし、そんな延期は、受け入れられるわけがない。conceptをC++0xから削除するのが、もっともマシな選択肢だったのだ。一方、委員会はconceptに賛成であり、将来、まともな提案をひっさげて、また議論することだろう。次の記事では、この失敗から学んだ事と、将来の方法について語ろうと思う。