しまったあああぁぁぁーーー！！！
「イヌ耳な幼馴染が欲しい」って3回お願いするの忘れてたあああぁぁぁーーー！！！
http://www.sponichi.co.jp/society/flash/KFullFlash20060329050.html
異常に速度の遅い流星で，20秒は目視できていたから，このお願いも不可能じゃなかったのにっ……なんたる……不始末っ！！
＃つか，関西での目撃報告がにゃいにゃぁ．オレは運が良かったのかにゃ？
Lambda/Closure in C++0x
http://www.tietew.jp/cppll/archive/12614
http://www.kmonos.net/wlog/59.php#_2335060328
ラムダ/クロージャの言語レベルサポートが 0x で実現するかというと，それはかなーり難しいのではないかというのがちょー個人的な予想．
ラムダ/クロージャの言語サポートは，設計として取りえる幅が広い（これはN1968でも指摘されてる）のだけれど，これは単純な技術的難しさ以上に標準化への大きな妨げになる可能性が非常に大きい．設計の幅というのは単に文法の問題だけではなくてラムダ/クロージャの根本に関わる部分も含めて．また C++ 固有の問題もあるといえばあるし．例えば，（そもそもクロージャに第1級オブジェクトの資格を付与するかどうかの設計の幅はあるけれど，今仮に）クロージャに第1級オブジェクトの資格を付与する場合で，（enclosing scope の自動変数への参照をそもそも許すのか？という設計の幅があるけれど，今仮に） enclosing scope の自動変数への参照を許すとして（ここで参照ではなくてコピーを取るという設計の幅があるけれど，今仮に参照として）， auto/dynamic の各 storage duration の区別が明確で，言語での GC な機構が存在しない C++ で参照先の変数の寿命をどう扱うんだ？とか，標準化できるレベルに議論を突き詰められるかと問われると……う〜ん． c.l.c.m でもラムダの話題は出てくるたびにえらいことになる，という印象しかない．
よっぽど強烈な技術的ブレイクスルーか，よっぽど泥臭い政治的根回しがない限り 0x での標準化はむりぽな印象．あくまで個人的な印象ですからね！
で，「なんであんなのをライブラリレベルで提供するんだ」とけちょんけちょんに言われることもしばしばの Boost.Lambda ですが，少なくとも今後どのようなラムダの言語レベルサポートが出てこようとも， _1 + 1 とか _1 > _2 などといった構文においては Boost.Lambda より短く簡潔に書けるようになることは（恐らく）決してない，という意味においては非常に強力であることは間違いない．実際 Boost.Lambda は，現在出ているラムダの言語サポートの提案で強烈に意識され，ライバル視されているわけで．そして今後も出てくるであろう全てのラムダの言語サポートの提案に強烈に意識され続け，ライバル視され続ける存在であることは間違いないわけで．
一方であまり議論に上らないのが不思議だけれど，直接的なラムダのサポートではなく，全く別の方向の言語機能拡張によって Boost.Lambda のようなライブラリでのソリューションが現状抱える問題点が改善される，という方向性も当然想定されるわけで．個人的には例えばスマートリファレンスのサポート（operator. のオーバーロード）なんかを想定していたりするんですが，
std::vector< std::pair< int, int > > v; ..... std::sort( v.begin(), v.end(), _1.first < _2.first );
まぁこれはこれで色々難しいとは思うけれど（スマリの議論の例は例えば『C++の設計と進化』とか参照）．
Move Semantics for Functional Aspect of C++
で，個人的にはラムダ/クロージャはどちらかといえば（0x での標準化が無理だと思っているので）どうでも良くて，やはり 0x といえばむぅぶせまんちくすなのです．あくまで個人的に，だけれど．
ただ，「ラムダ/クロージャよりは Move Semantics」とは言っているけれど，それは別に C++ の関数言語的側面を軽視しているわけでは全然なくて，むしろ Move Semantics によって C++ の関数言語的側面がより強化される，という個人的（かつ勝手）な期待があるので，
- コピーが重いオブジェクトも値返し -> 関数の引数に副作用がなくインタフェースもすっきり -> コンポジションを用いたシンタックスとの親和性の向上
- リソースの「移動」を発展させて，環境の「移動」（クロージャ）という応用観点での Move Semantics
そういう意味でもやっぱりむぅぶせまんちくすなのです．あくまでちょー個人的に．
＃にゃんで Move Semantics で盛り上がらないのかにゃー．直接的な利点として見えている部分がニッチ過ぎる（ように見える）のが悪いのかにゃー．
