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++の設計と進化』とか参照）．
