.Netのラムダ式で使用されている「=>」を発音するには

他のプログラマーに会うことはほとんどありません！

トークンを最初に見たときの私の考えは、「それを暗示する」ことでした。それは、それが数学的な証明でそれを読み取るものだからですが、明らかにそれは意味がありません。

だから私はどのように言うか「=>」のように読みます：

IEnumerable<Person> Adults = people.Where(p => p.Age > 16)

それとも、合意された言い方さえありますか？

その演算子を読むとき、私は通常「そのような」と言います。

あなたの例では、p => p.Age> 16は「p、p.Ageが16より大きい」と読みます。

実際、私は公式のlinqプレリリースフォーラムでまさにこの質問をしました、そしてAnders Hejlsbergはこう答えました

私は通常、=>演算子を「なる」または「そのため」と読みます。たとえば、
Func f = x => x * 2;
Func test = c => c.City == "London";
「xはx * 2になります」および「c.Cityがロンドンに等しいc」と読みます。

「に行く」限り-それは私には意味がありません。「p」はどこにも行きません。

電話で誰かにコードを読む場合、彼らが仲間のC＃プログラマーである限り、「ラムダ」という言葉を使用するだけです。つまり、「pラムダpドットエージより大きい」 16。"

コメントの中でスティーブジェソップは、変換の場合の「マッピング先」について言及しました。アンダースの例を見てみましょう。

x => x * 2;

読みます

xはx倍にマップします2。

これは、この場合の「なる」よりも、コードの実際の意図に非常に近いように見えます。

MSDNから：

すべてのラムダ式は、ラムダ演算子=>を使用します。これは、「移動先」として読み取られます。

電話でコードを読む

Eric Lippertから：

私は個人的にはc => c + 1と言って「see plus to see one plus」と言っています。私が聞いたいくつかのバリエーション：

プロジェクションの場合、（顧客c）=> c.Name： "顧客は、ドット名になります"

述語の場合、（顧客c）=> c.Age> 21：「顧客は、ドットエージが21より大きいように見えます」

私はいつもそれを「ワンオペレーター」と呼んできた:-)

「pの年齢が16より大きいpワン」

人々が「矢」と言うのを見たことがあります。

LINQブックで次のように指示されたため、「行く」を使用しています:)

「にマップする」はどうですか？それは簡潔であり、間違いなく技術的に正確です（つまり、「行く」または「なる」などの状態変更の提案はありません。「など」または「そのため」などの特徴的な機能を持つセットの融合はありません）他の選択肢。MSDNページが示唆するようにすでに標準が存在する場合でも、おそらくそれを（少なくともC＃コードの場合は）続行する必要があります。

「マップ先」は私の好みの発音です。数学的に言えば、関数はその引数を戻り値に「マップ」します（関数を「マッピング」と呼ぶことさえあるかもしれません）。そのため、プログラミングで、特に関数型プログラミング（特にラムダ計算）としてこの用語を使用することは理にかなっています。数学に非常に近いです。また、コンテキストフリーが言及しているように、状態の変化を示唆しないため、「になる」、「移動する」などよりも中立的です。

あまり考えたことはありませんが、簡潔に「と」とだけ言っています。これは短くて簡潔であり、変数が式に渡されることを意味します。数字の2（「2」）と混同されるかもしれませんが、話すときは「た」を「た」のように発音しがちです。（少なくともラムダを知っている）誰も私にあいまいだと思ったと言ったことはありません...

// "Func f equals x to x times two"
Func f = x=> x * 2;

// "Func test equals c to c dot City equals London"
Func test = c => c.City == "London"

私の短い答え：「c 'lambda-of' e」。私は「 'lambda' c 'function' e」にしがみついていますが、lambda-ofはエキュメニカルな妥協案だと思います。分析は次のとおりです。

これは、奇妙な答えだけの場合は素晴らしい質問です。ほとんどの翻訳には、ラムダ式以外の意味があり、エキゾチックな解釈につながります。古いラムダ式ハッカーとして、私は.NET表記を無視して、頭の中でラムダとして書き直します。

電話でコードをナレーションするには、誰かがコードを順番に書き留められるようにする必要があります。もちろん、それは問題ですが、おそらくラムダ矢印または何かがあなたが得ることができる最高のもの、あるいはラムダインですが、ラムダオブが最も正確です。

問題は、中置の使用法と、中置の場所で話されたときに機能する何かで全体と左と右の部分の役割に名前を付ける方法です。

これは過度に制約された問題である可能性があります！

私は「そのような」を使用しません。これは、右側が左側で満たすべき述語であることを意味するためです。これは、左側が機能パラメータとして抽象化された右側について話すこととは大きく異なります。（「すべてのラムダ式」に関するMSDNの声明は、不快であるだけでなく、単に攻撃的です。）

それは私たちが得ることができる限り近いかもしれませんが、何かが「行く」について不平を言います。「移動先」は変換を意味しますが、cの式に移動する変数cは正確にはありません。関数への抽象化は少しとらえどころのないです。私はこれに慣れることができましたが、それでも変数の抽象化を強調する何かに憧れています。

これまでに使用したケースでは、左側は常に単純な識別子なので、[後でこれを混乱させる可能性がある拡張機能を待つ]、 "c =>式"と考えると、 "c 'lambda-function' expression 「」または「c 'arg」「関数」式」。最後のケースでは、「b 'arg' c 'arg' 'function' expression」のように言うことができます。

ラムダ式が導入されていることをさらに明確にして、「 'arg' b 'arg' c 'function' expression」のようなものを言うのが良いかもしれません。

これらすべてを他の言語に翻訳する方法を理解することは、学生のための練習です[; <）。

「（b、c）=>式」や、まだ存在していない場合に発生する可能性のある他のバリアントについてはまだ心配しています。おそらく「 'args' b、c 'function' expression」でしょう。

このすべてを熟考した後、「c => e」を「 'lambda' c 'function' e」として翻訳し、正確な形式へのマッピングはコンテキストによって理解されることに気づきます。λc（e ）、c => e、f ここで f（c）= eなど

これは、支配的な大多数が初めてラムダ式を目にする場所だからです。それは残念だ。適切な妥協案は、「c ' lambda-of ' e」かもしれません。

ラムダ式を無名メソッドであると想像すると、「先に行く」というのはまともな意味があります。

(n => n == String.Empty)

n n == String.Emptyという式に「移動」します。

それは無名メソッドに行くので、コード内のメソッドに行く必要はありません！

そのために残念。

正直なところ、頭に「行きたい」を使うのは好きではありませんが、他の人が変だと思っているのを見て、それをはっきりさせたいと思いました。

上記のスコープ（ラムダ式が発生する時点でコードの通常の行のスコープ内にあるすべての変数と定数は、式のコードで利用可能です）を取得することとは別に、ラムダ式は本質的にインライン関数の構文糖衣です。

プロダクションオペレーターの左側にある値のリスト（ "=>"）は、この関数の呼び出しに使用されるスタックフレームの構造と内容に影響します。値のリストは、パラメーター宣言と渡される引数の両方に寄与すると言えます。従来のコードでは、これらは関数の呼び出しに使用されるスタックフレームの構造と内容を決定します。

その結果、値は式コードに「移動」します。「スタックフレームを定義する」または「移動先」と言いますか？:)

フィルター条件として使用されるブール式の狭義に定義されたアプリケーション（この質問に対する他の回答で広く検討されているラムダ式の主な使用法）では、コードの目的のためにメソッドをスキップすることは非常に合理的であり、これは「そのため」と同じくらい簡潔であり、コードの意味についてより多くのことを言っています。

ただし、ラムダ式はLinqの唯一の州ではなく、このコンテキスト以外では、より一般的な形式の「goes to」を使用する必要があります。

しかし、なぜ「行く」のですか？

「次のコードのスタックフレームにデータを入力する」は長すぎるので、それを言い続けることができません。「に渡される」と言えるかもしれません。

明示的に渡されたパラメータとキャプチャされた変数の重要な違いは（私が正しく覚えている場合-私が間違っている場合は修正してください）、前者は参照によって渡され、後者は値によって渡されるということです。

問題の一部は、それがどのように構造化されているかによって、大きく読み上げることができるということです。ルビーの|ほどきれいではなく、統合されていないのは残念です。

Rubyでは、この同じsybmolは「ハッシュロケット」と呼ばれ、C＃プログラマーもこの用語を使用していると聞きました（そうするのは間違っていますが）。

私の2セント：

s => s.Age > 12 && s.Age < 20

「パラメータsのラムダ式は{ return s.Age > 12 && s.Age < 20;}です」

ランバの表現がどこから来たのかを思い出させるので、私はこれが好きです

delegate(Student s) { return s.Age > 12 && s.Age < 20; };

=>は単なるショートカットなので、コンパイラが推測できるため、デリゲートキーワードを使用して型情報を含める必要はありません。

結果の表示例に適用される=>の私の用語

'result = s => s.Age > 12 && s.Age < 20'

s s.Ageが12より大きく、s.Ageが20より小さい場合

'result = x => x * 2'

x xは2倍されます

'result = c => c.City == "London"'

cここで、c.cityは「ロンドン」と同等です

'result = n => n == String.Empty'

n（nは空の文字列）