C++0x、コンセプト除外の決断というタイトルで、Bjarne Stroustrup博士がDr.Dobbsに7月22日付けで寄稿していた。その中でも、「何が起きたのか」について語っているくだりを読みながらメモしているうちに勝手な訳文ができてしまったのでせっかくだからメモ。要は今回はタイミングが合わなかったっていうことなのかなあ。
何が、起きたのか？
コンセプト、過去何年間にもわたって、開発され、C++0Xのワーキングペーパにも組み込まれてきたそれは、ある種の技術的な妥協（しかしそれは自然で必要なものだった）を含んでいた。実験的に実装されたそれは、概念的に確立された標準ライブラリとしてテストするには十分なものであったが、製品としての品質を備えてはいなかった。この後半の事情がある人々を不安がらせもした。しかし、私はそれが原理証明としては十分なものであると考えていた。
私が心配していたのは、コンセプトの設計そのもの、とくに、平均的なプログラマーにそれが渡ったときの使いやすさだった。同じ認識のメンバーも数名いたように思う。もともと謳われていたコンセプトの目的とは、ジェネリック・プログラミングを大多数のプログラマにとってより身近なものとすることだったが、そのもくろみは、深刻なレベルで妥協の中に埋もれてしまったかに私には見えた。つまりジェネリックプログラミングを誰でも使える、より身近なものにするどころか、コンセプトは、一部の熟練プログラマーだけが使える難しい道具への、さらなる追加でしかないようなものになってきてしまっていた。
この半年間あまり、私はC++0Xというものをユーザー視点から検証する中で、コンセプトを使って実装されたライブラリを使うだけでも、プログラマーに新たな重荷を課すことになりはしないだろうかということが心配になっていた。
コンセプトの設計とその標準ライブラリにおける使い勝手は、我々が過去数年間にわたって描いてきたその構想を適切に反映するものでさえなくなってしまっているなと私は感じるようになっていた。
そして数ヵ月前、AlisdairMeredith氏（洞察力のあるUKのメンバー）と、Haward Hinnat氏（標準ライブラリーワーキンググループの長）が、誰が、どのようにして、コンセプトのどの機能を、直接使うべきなのかという内容の、核心をついた質問をしてきた。それは、使い勝手に関する議論を引き起こし、さまざまな関心や視点を持った人々を巻き込むこととなった。
結局私は、大いに混沌を極めた議論の後に、BS2009に、私自身の結論をまとめた。それはおおざっぱには次のような内容であった。
- 現在定義されているものとしてのコンセプトは、使い方がとても難しいものとなっており、それは結果として、コンセプトそのものは勿論、ともすればテンプレート、ついには、C++0Xそのものを、使われないものにしてしまう可能性がある。
- BS2009に示した、コンパクトな簡略化案が、コンセプトを、最小限の労力で、現在のC++0xのスケジュールに乗せていくに足る、十分に良いものへと導く方向を示唆するものである。
それはなかなか強烈なものであった。標準化委員会は通常は礼儀正しい場であり、また合意を目指している以上、我々は直接的な対峙は避けようとする向きがあることは理解して頂きたい。しかし、不幸にして、結果として巻き起こったその後の（内部的な）議論は、非常に膨大なもの（細に入った議論を綴ったメッセージは数百にも及んだ）となり、混沌を極めた。どの問題に、どう取り組むかについて、いかなる合意が成立することもなかった。この結果私はフランクフルトでのプレゼンテーションにて、以下のような選択肢を提供することになった。
- Fix and ship（直して乗せる）
- 残ってる仕事：explicit"concepts"の除外、explicit refinement、"concept"/type matchingの追加、conceptマップスコープの問題の解決
- リスク：実装なし、説明の煩雑化
- スケジュール：変化なしか、会議が一つ増える
- Yank and ship（破棄して乗せる）
- 残ってる仕事：破棄する（コアと標準ライブラリ）
- リスク：従来のテンプレートの問題はのこったまま、7年間縁の下で頑張ってきた改革メンバーたちの失望
- スケジュール：根本から設計をやりなおしたコンセプトを5年間で確立するかもうしないか
- Status quo そのままの状態
- 残ってる仕事：多々
- リスク：受け入れにくいプログラミングモデル、説明の煩雑化
- スケジュール：変化なし
私と仲間たちは第一の選択肢（修正して乗せる）を推し、それは現実的で、実現可能だと考えていた。しかし、委員会の大多数はこれには反対で、二つ目の選択肢を推した。（破棄して乗せる、言い換えれば切り離しだ）私としては両者は3つ目の選択肢「現状維持」よりはましだと思う。
この投票結果の私の解釈は、もともとC++0Xの野心的なスケジュールについて心配する人々（そしてコンセプトを卑怯（個人的見方だが）にも非難する人々）や、始めからコンセプトに何ら情熱を傾けていなかった人々にとって、コンセプトの提案者・支持者の中に意見の不一致があるのをみたとたん、全てのアイデアが論争の的であるかのように見えてしまったということだ。そしてその結果、コンセプトの修正案は、もはや彼らの選択枝からは失われてしまうこととなった。基本的に皆が示したコンセプトへの支持は、あとでとかそのうち、というものばかりだった。しかし私は、もしここでコンセプトを除外すれば、それが世に出るまでには長期間の遅延が避けられないだろうと警告した。全ての設計判断は本質的に、スケジュール的な圧力なしでは、常に再検討が行われるものだからである。
驚いた（かも知れない）ことには、このフランクフルトでは、コンセプトについての技術的な発表や議論は一切されなかったのである。タイミングに関することに議論は集中し、今回の可決は、時間的な心配による要因が主だったのではないかという印象を私は持っている
慎重な姿勢を崩さない委員会を非難しないで欲しい。これは、Bjarne対委員会の対決ではなく、複数の深刻な不安を調和させる試みとしての議論である。私と仲間たちは、fix and ship の機会を得られなかったことに失望しているが、C++は試験的、学術的な言語ではない。製品のコードを害するリスクが非常に小さいことを委員会のメンバーが理解していない限りは、彼らは反対しなければならない。
集団として、委員会は数億行にもわたるコードについて責任を持たなくてはならないのだ。例えば、C++0Xに適合できない事例や長期にわたる、拘束を欠いたテンプレートの継続的な使用は、C++委員会を別々に分かれたいくつかの分科委員会に分断してしまうかもしれない。だから、現時点でのコンセプトの設計が貧弱であれば、それはむしろない方がいいのである。
二者択一をするにあたり、結局私も削除の方に投票した。起こりそうとわかっている災害に対しては、私も予防策を選ぶ。
