このような「ランタイム」演算子内のメソッドグループのように、CLRでランタイム表現なしでC#言語要素を使用できるようにする目的/ポイント/理由は何ですか?
言語設計ノートのアーカイブには、この決定がなされた理由が記載されていないため、答えを推測することは推測になります。彼らは、「is」の結果が常に真または偽であると静的に決定できる場合、それがそのように決定され、警告を生成すると述べています。これは単にエラーである可能性があります。
当然のことながらエラーになる可能性のあるものを警告に変える(または単にそれを許可する)最も一般的な理由は、コードを自動的に生成するプログラムの作成者の負担を軽減するためです。ただし、ここでは本当に説得力のあるシナリオは見当たりません。
アップデート:
C#1.0の仕様を確認しました。この言語は含まれていません。nullやメソッドグループの引数については何も述べていません。そしてもちろん、C#1.0では暗黙的なメソッドグループ変換がなかったため、メソッドグループ変換については何も述べていません。メソッドMをデリゲートタイプDに変換する場合は、明示的に「new D(M)」を呼び出す必要がありました。
この後者の点は、「MisD」がtrueではなくfalseを返すことの正当化です。法的に「Dd=M;」とは言えません。では、なぜ「MはD」が真である必要があるのでしょうか。
もちろん、C#2.0では、「D d = M;」と言うことができるので、これはあまり意味がありません。C#2.0で。
また、「is」演算子が設計されたときに出席した人の1人に尋ねたところ、彼はこの質問を何らかの方法で決定した記憶がありませんでした。彼の疑惑は、「is」演算子の元の設計はエラーを出さず、警告のみを与えることであり、メソッドグループとnullの処理方法に関する仕様のすべてのテキストと、事後的に追加されたものでした。仕様のC#2.0バージョンであり、コンパイラが実際に行ったことに基づいています。
要するに、これはC#2.0の仕様が更新されたときにペーパーオーバーされたC#1.0の設計上の穴だったようです。この特定の動作が望まれ、意図的に実装されたようには見えません。
この理論は、匿名メソッドがC#2.0で「is」の引数として使用されるとエラーを生成するという事実によって補強されています。そうすることは重大な変更ではありませんが、「M is D」が突然trueを返し始めたり、エラーになったりすることは重大な変更になります。
さらなる更新:
これを調査している間、私は何か面白いことを学びました。(私にとって。)機能が最初に設計されたとき、設計は、タイプの名前、または「is」の右側の引数としてTypeオブジェクトのいずれかを許可することでした。ただし、C#1.0が出荷されるかなり前に、そのアイデアは放棄されました。