たちと同じですが、実は言語仕様面から見たらかなり別物です。単なる演算子というより、言語組み込みの構文です*5。左側の評価結果を、右側の関数呼び出しの先頭の引数にします(最後ではなく先頭)。ふつうの二項演算子であれば、左右の式は独立した式になります。どちらも単体で成立する式ですよね。単体で成立する関数です。引数を複数取る関数のときは、カリー化を活用して部分適用しておきます。パイプラインで渡したい「プライマリ」の引数は最後なので、これがピタッとハマります。右側は、単体の関数呼び出し式として見ると引数が足らないので、独立していません。演算子というより構文と言うべきでしょう。満たしていないためです。中置演算子を自由に増やすことはできず*6、デフォルトのカリー化はなく、主要な引数を最後に受け取る関数群の一貫設計もありません*7。パイプライン演算子の見た目だけを真似たもので、個人的な感覚では完全な別物、という印象です。いえ、実用プログラミング言語の設計においては見た目こそが重要なことであり、言語マニアから見て別物とかは、ユーザ視点ではどうでもいいことです。試験的に導入されたパイプライン演算子の話です。左側の式の評価結果をレシーバとして、右の名前のメソッドを呼び出します。前述のポイントを満たしていません。よって、単なる演算子ではなく構文として導入する必要がありました。左側の式を右側の関数呼び出しの第一引数としました。右側のメソッド呼び出しのレシーバとしています。メソッドにおける「プライマリ」な引数がレシーバであることを考えると、ある意味で自然な設計です。何がうれしいかというと、複数行に渡るメソッドチェーンを明示的に書いたり、括弧を省略できたりするというのが挙げられます。}下のほうが簡潔でよい、という人がいることを否定することは出来ません。(自分もすごい良いと思ってるのかというと、まあそこまでではないんですが)一方で問題点もあります。慣れた人たちにはわかりにくい従来のメソッドチェーンとできることが変わらないので意義が乏しい前者については、自分が知る限りレシーバという概念がある言語にはじめてパイプライン演算子を導入する事例なんですよね*8。違う!」とだけ言ってもしょうがない。合わせる需要が少ない可能性も考えられます。月までもうちょっとゆっくり考えてみてもよいのではないかと、個人的には思っています。このあたりの問題点の指摘をうけて、現在名称や記号の変更が検討されています。「パイプライン演算子」は幻想で終わってしまうのか、生暖かく見守っていきましょう。まとめパイプラインの歴史を駆け足で追ってみました。言及がない!っていう悲しみの声を聞きます。パイプライン演算子の先祖(と自分が思っているもの)だけを書きました。他の言語にもありますが、まともに調べてないので詳しい言及はせず、知ってる範囲で列挙だけしておきます。