C++0x
新バージョンの年の下一桁を埋めておく文字は何故C/C++はxでAdaはyなのか、という疑問はさておき*1C++に疎い小生かなり時代遅れでC++の改定の話を知りましたのでメモを残そうとしたら、これがいつもの癖で好き勝手書いてみたくなりましたので書きます。
墓下で狂勇者を眺めてるような気分でお読みください、いやむしろ読むな。
http://www.gotw.ca/publications/index.htm
http://lambda-the-ultimate.org/node/view/824
http://www.research.att.com/~bs/evol-issues.html
http://www.lafstern.org/matt/wishlist.html
(ES004) template typedef。
うん、自然な拡張かつ必要なものに思えます。
(EP001) autoでローカル変数をtypeof(初期化式)の型に。
C#3.0でもあちらこちらでさんざん噂されてますが、こういうのは型推論とは言わないんじゃないかなー。現時点でもコンパイラは知っているはずの情報ですから。単にsizeofの延長。でも便利でしょうね。C++は特にtemplateをtypedefせずに引数含めてべた書きする習慣があるみたいですし、イテレータとかもう大活躍でしょう。
(ES026) 配列を受け取ることができるコンストラクタ。
C++のclassの設計コンセプトっぽい「ユーザー定義を組み込み型と同じように」を進めた形。ただコピーコンストラクタもそうですが、予約語にすべきはexplicitではなくてimplicitだったと小生思うのです。あとvectorを配列のように書けるようにするぐらいなら組み込みの配列を強化すりゃいいのに…。いや、例がvectorなだけで、実際にはコンストラクタでstrlen呼ばなくて済むようになるstringのほうが嬉しいか。
(EP010) concept, model, where等なんだかHaskellのclassっぽいtemplateの制約。
あまりにも今更といえば今更でしかも従来単にオーバーロードで済んでたものが定義の書き直しが必要っぽい*2とくれば誰も使わない予感。これに合わせて標準ライブラリは全部直されるのでしょうか？
以上がほぼ確定っぽいもの。以下はwish listから。
ES024. Properties. Provide Delphi/C# like properties. It may be possible to provide properties as a standard-library facility.
過去幾人もがoperator使ってマクロ作ってるのも知ってますが、C++には果てしなく似合わないよーな…。++演算子と相性悪いですし、Dのは事実上括弧が無くても関数が呼べる構文ですがそのために関数名だけだとアドレス、というルールは捨ててますしね。
それとこれ。
E051. Derived enumerations Allow derived enumerations. For example: enum B { a, b }; enum D : B { c, d }; // members of D are a, b, c, and d
これですとBのスーパータイプを複数定義できることになってしまいませんか？継承というのは型の上ではサブタイプなので、列挙型に対応させるなら部分範囲になるのが正しいと思います。ES074も全く同じか？重複あるなこれ。
ついでにES052. All C99 extensionsが導入されたら、complexヘッダーは完全にごみと化しますね。
一方ですごく要望がありそうなlambda(ES017)は????。関数内関数(ES046)も????。
なまじトリッキーなメタプログラミングが発達したせいで後回しになる予感。inlineキーワードを使いまわしてlambdaなんて案はあることはあるらしい。文法化されたらBoostの半分ぐらい無駄になるのでは…。それはそれで愉快ですが。
うん、boost/lambdaなどが無駄になるのと比べればcomplexぐらいなんでもないですね。なお小生どちらも使ったことはありません。
ES061は…Adaと逆の道…。template考えたらメソッドも関数構文で呼べるほうが有利なのは事実です、が、機構としてはconceptと別物になっちゃうのでは。どうなんだろ。
wish list長すぎという話は、Ada2005の軽く総数500超えしているIssuesを見れば、全然そんなことは無いと思います。むしろえらい小規模のような…。言語機能のデモのためだけにコンソール出力に何重ものtemplateとvirtual継承まで使った勢いはどこへ…。*3
ここはstd.stream.stdoutをstd.cstream.doutに改名するぐらいの派手な…あー。stdoutの名前を再利用しているのはC++とは別ルートを辿ったCの後継を象徴してるみたいで気に入ってたのになー。doutだとC++意識しすぎかつ意味不明ですよー。*4何の話だ。閑話休題。なにやらstd2とか怪しい話もありますが、標準がヘッダーにトリック仕込むって…。そこまで大事か互換性。*5
あと小生ならC/C++を改定する機会があれば全てを差し置いてもまともなモジュール化機構導入するのですが、そんな話はなりを潜めている様子(一応ES023、????ですが)。うまくやれば従来のソースは全部匿名モジュールなりグローバルモジュールなりといった扱いで隔離できると思うのですけれども。
次点は配列ですね。vectorなんざ強化するよりは配列をsizeof以外でも値として使える普通の値型にして欲しいです。std::arrayなんて話まで出る今のC++では無意味ですかそうですか。
他には型の係り受けの順をD言語並び希望ですがこれは流石に…なんて思ったら出たdecltype！すげー。まじですかー。すげー。これ通ったら尊敬しますよ。尊敬と同時にますますC++が嫌いになれそうでもありますが。
あと何かあるかな…。
細かいところでコンパイラに引数が値渡しか参照渡しか裏で判断できる権限とか導入したらどうでしょう。Delphiそのままにconstつけといたら勝手にそういう扱いになるとかそんな感じで。templateのために参照の参照は参照なんてルール作るよりも、絶対効果的と思うのです。バイナリ互換性？dllのヘッダーファイルで引数に無駄なconstが付けられてるのを小生見たこと無いですよ？
列挙型の最後まで回せるような後判断forとかも欲しいですが、ES034などを見ますにC系のenumはやっぱただの定数と割り切ったほうがいいのかしら。do ... whileに習えでdo(char c = 'A'){ ... }for(c <= 'Z'; ++c);ぐらいならバチ当たらないように思えるのですけれども。foreachやPascal系の増分±1固定forは、イテレータ全盛のC++には似合わないかな。
最後に予想。ES039はボツと読みます。理由はC/C++は言語組み込みの文字列比較演算を持ってないから…の一方で、switch(p; strcmp){ ... }ならあり得るかもと思ってしまう自分もいるので何かを賭けたりはしません。それにしてもcaseに文字列という要望は言語を問わずやたら見かけますが、列挙型と任意の文字列群を簡単に対応付ける機能さえあれば、そっちがよほど便利では…というか欲しい。Adaの'ImageやDelphiのRTTIは識別子縛りがあるので若干不自由なのです。
ええと、C++は、templateの特殊化がたまたまメタプログラミングに使えてしまったがために、そちら方面ばっかり拡張されて、ラベルつきbreakみたいな基本的な部分の拡張話が全く出てこないというのは、不幸と思いますです。
