http://d.hatena.ne.jp/mb2sync/20061205#p1
これ以前導入しようとしたけれども， lambda functor と組み合わせたときに， lambda functor としての operator| か pipable function の operator| かが曖昧になるから回避してたにゃあ．でも，今よくよく考えたら lambda functor である外皮は直接 pipable とせずに， lambda functor によって wrap されてる action だけ pipable にすればきれいに機能させられる気がしてきた． Boost.Lambda ってそういう構造になってたっけ？なってたはずなんだけれど．も一回 Boost.Lambda のコード読み直すか．多分あまり難しい注文ではないはず．
これが導入できれば， range view 固有に operator| を導入せず， range view を1項の (多相) 関数オブジェクトクラスとして汎化した上で，これに対する piping operation として range view に対する operator| (composition) を定義できる． range view を1項の (多相) 関数オブジェクトクラスとする設計はもともとそうなんだけれど．
ただ， range view を (多相) 関数オブジェクトクラスとして定義すると， object generator と range view の2足のわらじを履かせることができなくなるケースがあるけれどどど．
v | view::sort // view::sort はデフォルトの ordering を用いた range view として機能 v | view::sort( _1 > _2 ) // view::sort は ordering を明示的に指定した range view を生成する object generator として機能
これができにゃーい．さて，どうするかにゃー． range が range であると non-intrusive に annotate する方法はあるけれどおおおぉぉぉ．そんにゃ面倒くさいことはさせたくにゃーい．
