メソッドを追加することで曖昧な呼び出しに関与しない場合に、あいまいな呼び出しを追加する理由

私はこのクラスを持っています

public class Overloaded
{
    public void ComplexOverloadResolution(params string[] something)
    {
        Console.WriteLine("Normal Winner");
    }

    public void ComplexOverloadResolution<M>(M something)
    {
        Console.WriteLine("Confused");
    }
}

私がそれをこのように呼ぶと：

        var blah = new Overloaded();
        blah.ComplexOverloadResolution("Which wins?");

Normal Winnerコンソールに書き込みます。

しかし、別のメソッドを追加した場合：

    public void ComplexOverloadResolution(string something, object somethingElse = null)
    {
        Console.WriteLine("Added Later");
    }

次のエラーが発生します。

呼び出しは次のメソッドまたはプロパティ間であいまいです：> ' Overloaded.ComplexOverloadResolution(params string[])'および ' Overloaded.ComplexOverloadResolution<string>(string)'

メソッドを追加すると、呼び出しのあいまいさが生じる可能性があることは理解できますが、それは、すでに存在している2つのメソッド(params string[])と<string>(string)！1つはパラメータであり、2つ目はジェネリックであるため、あいまいさを伴う2つのメソッドのどちらも新しく追加されたメソッドではないことは明らかです。

これはバグですか？仕様のどの部分がこれが当てはまると述べていますか？

これはバグですか？

はい。

おめでとうございます。オーバーロードの解決でバグが見つかりました。このバグはC＃4および5で再現されます。セマンティックアナライザーの「Roslyn」バージョンでは再現されません。私はC＃5テストチームに通知しました。うまくいけば、最終リリースの前にこれを調査して解決できます。（いつものように、約束はありません。）

正しい分析が続きます。候補者は次のとおりです。

0: C(params string[]) in its normal form
1: C(params string[]) in its expanded form
2: C<string>(string) 
3: C(string, object) 

にstring変換できないため、候補ゼロは明らかに適用できませんstring[]。それは3つを残します。

3つのうち、私たちはユニークな最良の方法を決定する必要があります。残りの3つの候補をペアごとに比較することでそれを行います。このようなペアは3つあります。省略されたオプションのパラメーターを取り除くと、それらはすべて同じパラメーターリストを持ちます。つまり、仕様のセクション7.5.3.2で説明されている高度なタイブレークラウンドに進む必要があります。

1と2のどちらが良いですか？関連するタイブレーカーは、ジェネリックメソッドは常に非ジェネリックメソッドよりも悪いということです。2は1より悪いので、2が勝者になることはできません。

1と3のどちらが良いですか？関連するタイブレーカーは次のとおりです。その拡張形式でのみ適用可能な方法は、通常の形式で適用可能な方法よりも常に劣ります。したがって、1は3よりも劣ります。したがって、1が勝者になることはできません。

2と3のどちらが良いですか？関連するタイブレーカーは、ジェネリックメソッドは常に非ジェネリックメソッドよりも悪いということです。2は3より悪いので、2が勝者になることはできません。

複数の適用可能な候補のセットから選択するには、候補は、（1）負けていない、（2）少なくとも1つの他の候補を超えている、（3）最初の2つのプロパティを持つ一意の候補である必要があります。候補者3は他のどの候補者にも負けておらず、少なくとも他の1人の候補者に勝っています。このプロパティを持つ唯一の候補です。したがって、候補3は、独特の最適な候補。勝つはずです。

C＃4コンパイラーが間違っているだけでなく、奇妙なエラーメッセージが報告されていることを正しく認識しているだけです。コンパイラーが過負荷解決分析を間違っていることは、少し驚くべきことです。エラーメッセージが間違っていることは、まったく驚くことではありません。「あいまいなメソッド」エラーヒューリスティックは、最適なメソッドを決定できない場合、基本的に候補セットから2つのメソッドを選択します。「本当の」あいまいさを見つけるのは、実際にあるとしても、あまり得意ではありません。

それがなぜなのかを合理的に尋ねるかもしれません。「より良い」関係は自動詞であるため、「あいまいさがないあいまい」な2つの方法を見つけるのは非常に難しいです。候補1が2より優れている、2が3より優れている、3が1より優れているという状況が考えられます。

Roslynのヒューリスティックを改善したいのですが、優先度は低いです。

（読者への演習：「線形時間アルゴリズムを考案して、n要素のセットの一意の最良のメンバーを特定して、より良い関係が非自発的である」というのは、このチームにインタビューした日に私が尋ねられた質問の1つでした。非常に難しいアルゴリズムです。試してみてください。）

C＃へのオプションの引数の追加をあまりにも長く延期した理由の1つは、オーバーロード解決アルゴリズムに導入された複雑なあいまいな状況の数でした。どうやら、私たちはそれを正しく理解していませんでした。

Connectの問題を入力して追跡したい場合は、お気軽にご連絡ください。あなたがそれを私たちの注意を引くようにしたいだけなら、それは終わったと考えてください。私は来年のテストでフォローアップします。

これを私の注意を喚起してくれてありがとう。エラーの謝罪。

仕様のどの部分がこれが当てはまると述べていますか？

セクション7.5.3（オーバーロードの解決）、およびセクション7.4（メンバーの検索）および7.5.2（型の推論）。

特に「対応する引数のないオプションのパラメーターはパラメーターリストから削除されます」、および「M（p）が非ジェネリックメソッドである場合amd M（q）が一部含まれるセクション7.5.3.2（より良い関数メンバー）に注意してください。汎用的な方法では、M（p）がM（q）よりも優れています。」

ただし、仕様のどの部分がこの動作を制御するかを知るには、仕様のこれらの部分を十分に理解していません。それが準拠しているかどうかを判断することはもちろんです。

一部のメソッドで最初のパラメーターの名前を変更し、割り当てるパラメーターを指定することで、このあいまいさを回避できます。

このような ：

public class Overloaded
{
    public void ComplexOverloadResolution(params string[] somethings)
    {
        Console.WriteLine("Normal Winner");
    }

    public void ComplexOverloadResolution<M>(M something)
    {
        Console.WriteLine("Confused");
    }

    public void ComplexOverloadResolution(string something, object somethingElse = null)
    {
        Console.WriteLine("Added Later");
    }
}

class Program
{
    static void Main(string[] args)
    {
        Overloaded a = new Overloaded();
        a.ComplexOverloadResolution(something:"asd");
    }
}

params最初のメソッドからを削除した場合、これは起こりません。1番目と3番目のメソッドは両方とも有効な呼び出しを持っていますがComplexOverloadResolution(string)、最初のメソッドがpublic void ComplexOverloadResolution(string[] something)曖昧ではありません。

パラメータに値を指定object somethingElse = nullすると、オプションのパラメータになるため、そのオーバーロードを呼び出すときに指定する必要はありません。

編集：コンパイラはここでいくつかのクレイジーなことをしています。最初のメソッドの後にコードで3番目のメソッドを移動すると、正しくレポートされます。したがって、正しいものをチェックせずに、最初の2つのオーバーロードを取得して報告しているようです。

'ConsoleApplication1.Program.ComplexOverloadResolution（params string []）'および 'ConsoleApplication1.Program.ComplexOverloadResolution（string、object）'

Edit2：新しい発見。上記の3つからメソッドを削除しても、2つの間に曖昧さは生じません。したがって、競合は、順序に関係なく、3つの方法が存在する場合にのみ発生するようです。

1. あなたが書くなら

   var blah = new Overloaded();
   blah.ComplexOverloadResolution("Which wins?");

   または単に書く

   var blah = new Overloaded();
   blah.ComplexOverloadResolution();

   それは意志終わるのと同じ方法に方法では、

   public void ComplexOverloadResolution(params string[] something

   これは、パラメーターが指定されていないparams場合にも最適に一致する原因キーワードです

2. このように新しい方法を追加しようとすると

   public void ComplexOverloadResolution(string something)
   {
       Console.WriteLine("Added Later");
   }

   これは、パラメーターを使用した呼び出しに完全に一致するため、このメソッドを完全にコンパイルして呼び出しstringます。その後、はるかに強い params string[] something。

3. あなたがしたようにあなたは2番目の方法を宣言します

   public void ComplexOverloadResolution(string something, object something=null);

   コンパイラーは、最初の方法とこれを完全に混同し、追加したばかりです。それは彼があなたの呼び出しで今すべての機能をどのようにすべきかわからないからです

   var blah = new Overloaded();
   blah.ComplexOverloadResolution("Which wins?");

   実際、次のコードのように、呼び出しから文字列パラメーターを削除すると、すべてが正しくコンパイルされ、以前と同様に機能します

   var blah = new Overloaded();
   blah.ComplexOverloadResolution(); // will be ComplexOverloadResolution(params string[] something) function called here, like a best match.