Belirsizliğe dahil olmayacaksa, bir yöntem eklemek neden belirsiz bir çağrı ekler?

Bu sınıfa sahibim

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

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

Ben böyle dersem:

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

Normal WinnerKonsola yazar .

Ancak başka bir yöntem eklersem:

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

Şu hatayı alıyorum:

Çağrı, aşağıdaki yöntemler veya özellikler arasında belirsizdir:> ' Overloaded.ComplexOverloadResolution(params string[])' ve ' Overloaded.ComplexOverloadResolution<string>(string)'

Bir yöntem eklemenin bir çağrı belirsizliği getirebileceğini anlayabiliyorum, ancak bu, zaten var olan iki yöntem arasında bir belirsizlik (params string[])ve <string>(string)! Açıktır ki, belirsizliğe dahil olan iki yöntemden hiçbiri yeni eklenen yöntem değildir, çünkü birincisi bir parametredir ve ikincisi bir geneldir.

Bu bir hata mı? Spesifikasyonun hangi kısmı bunun böyle olması gerektiğini söylüyor?

Bu bir hata mı?

Evet.

Tebrikler, aşırı yük çözümünde bir hata buldunuz. Hata C # 4 ve 5'te çoğalır; anlamsal analizörün "Roslyn" versiyonunda yeniden üretilmez. C # 5 test ekibini bilgilendirdim ve umarım bunu son sürümden önce araştırıp çözebiliriz. (Her zaman olduğu gibi söz yok.)

Doğru bir analiz izler. Adaylar:

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

Aday sıfır açıkça uygulanamaz çünkü stringdönüştürülemez string[]. Üç kalıyor.

Üçü arasında benzersiz bir en iyi yöntem belirlemeliyiz. Bunu kalan üç adayın ikili karşılaştırmalarını yaparak yapıyoruz. Böyle üç çift var. İhmal edilen isteğe bağlı parametreleri çıkardığımızda hepsinin aynı parametre listeleri var , bu da şartnamenin 7.5.3.2 bölümünde açıklanan gelişmiş eşitlik bozma turuna gitmemiz gerektiği anlamına geliyor.

Hangisi daha iyi, 1 mi 2 mi? İlgili eşitliği bozan şey, jenerik bir yöntemin her zaman jenerik olmayan bir yöntemden daha kötü olmasıdır. 2 1'den daha kötüdür. Yani 2 kazanan olamaz.

Hangisi daha iyi, 1 mi 3 mü? İlgili eşitliği bozan şey şudur: Yalnızca genişletilmiş biçiminde uygulanabilen bir yöntem, her zaman normal biçiminde uygulanabilen bir yöntemden daha kötüdür. Bu nedenle 1, 3'ten daha kötüdür. Yani 1 kazanan olamaz.

Hangisi daha iyi, 2 mi, 3 mü? İlgili eşitliği bozan şey, jenerik bir yöntemin her zaman jenerik olmayan bir yöntemden daha kötü olmasıdır. 2, 3'ten daha kötüdür. Yani 2 kazanan olamaz.

Birden fazla uygun aday arasından seçilmek için bir adayın (1) yenilmemiş olması, (2) en az bir diğer adayı geçmesi ve (3) ilk iki özelliğe sahip olan benzersiz aday olması gerekir. Üçüncü aday başka hiçbir aday tarafından mağlup edilmez ve en az bir diğer adayı yener; bu mülke sahip tek adaydır. Bu nedenle üçüncü aday benzersiz en iyi adaydır . Kazanmalı.

Tuhaf bir hata mesajı verdiğini doğru bir şekilde not ettiğiniz gibi, sadece C # 4 derleyicisi yanlış anlamıyor. Derleyicinin aşırı yük çözümleme analizini yanlış anlaması biraz şaşırtıcı. Hata mesajını yanlış anlaması tamamen şaşırtıcı değildir; "belirsiz yöntem" hatası buluşsal yöntemi, en iyi yöntem belirlenemezse, temelde aday kümeden herhangi iki yöntemi seçer. Aslında varsa, "gerçek" belirsizliği bulmakta pek iyi değil.

Neden böyle olduğu sorulabilir. "Kesinlikle belirsiz" olan iki yöntem bulmak oldukça zordur çünkü "daha iyi" ilişkisi geçişsizdir . Aday 1'in 2'den daha iyi, 2'nin 3'ten daha iyi ve 3'ün 1'den daha iyi olduğu durumlarla karşılaşmak mümkündür. Böyle durumlarda ikisini "belirsiz olanlar" olarak seçmekten daha iyisini yapamayız.

Roslyn için bu buluşsal yöntemi geliştirmek isterim, ancak bu düşük bir önceliktir.

(Okuyucu için alıştırma: "Açıklık ilişkisinin geçişsiz olduğu bir dizi n öğenin benzersiz en iyi üyesini belirlemek için doğrusal bir zaman algoritması tasarlayın", bu takım için röportaj yaptığım gün sorulan sorulardan biriydi. çok zor bir algoritma; bir şans verin.)

C # 'a isteğe bağlı argümanlar eklemeye bu kadar uzun süre devam etmemizin nedenlerinden biri, aşırı yük çözüm algoritmasına getirdiği karmaşık belirsiz durumların sayısıydı; görünüşe göre doğru anlamadık.

Takip etmek için bir Connect sorununa girmek isterseniz, çekinmeyin. Sadece dikkatimizi çekmek istiyorsanız, yapıldığını düşünün. Önümüzdeki yıl testlerle devam edeceğim.

Bunu dikkatime sunduğun için teşekkürler. Hata için özür dileriz.

Spesifikasyonun hangi kısmı bunun böyle olması gerektiğini söylüyor?

Bölüm 7.5.3 (aşırı yük çözümü), bölüm 7.4 (üye arama) ve 7.5.2 (tür çıkarımı) ile birlikte.

Özellikle bölüm 7.5.3.2'ye (daha iyi işlev üyesi), kısmen "karşılık gelen bağımsız değişkenler olmayan isteğe bağlı parametreler parametre listesinden kaldırılır" ve "M (p) genel olmayan bir yöntemse, M (q) genel bir yöntemse M (p), M (q) 'dan daha iyidir. "

Bununla birlikte, şartnamenin bu bölümlerini, uyumlu olup olmadığına karar vermek bir yana, şartnamenin hangi bölümlerinin bu davranışı kontrol ettiğini bilebilecek kadar tam olarak anlamıyorum.

Bazı yöntemlerde ilk parametrenin adını değiştirerek ve atamak istediğiniz parametreyi belirterek bu belirsizliği önleyebilirsiniz.

bunun gibi :

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İlk yönteminizden kaldırırsanız , bu olmaz. Birinci ve üçüncü yöntemin her iki geçerli çağrısı var ComplexOverloadResolution(string), ancak ilk yönteminiz varsa public void ComplexOverloadResolution(string[] something)belirsizlik olmayacak.

Bir parametre için değer sağlamak object somethingElse = null, onu isteğe bağlı parametre haline getirir ve bu nedenle, bu aşırı yüklemeyi çağırırken belirtilmesi gerekmez.

Düzenleme: Derleyici burada bazı çılgın şeyler yapıyor. Üçüncü yönteminizi ilk yönteminizden sonra kodda taşırsanız, doğru şekilde raporlanır. Görünüşe göre ilk iki aşırı yüklemeyi alıyor ve doğru olanı kontrol etmeden onları rapor ediyor.

'ConsoleApplication1.Program.ComplexOverloadResolution (parametreler dizesi [])' ve 'ConsoleApplication1.Program.ComplexOverloadResolution (dize, nesne)'

Düzenleme2: Yeni bulgu. Yukarıdaki üç yöntemden herhangi bir yöntemi çıkarmak, ikisi arasında hiçbir belirsizlik yaratmayacaktır. Öyleyse öyle görünüyor ki, çatışma, sıraya bakılmaksızın, yalnızca mevcut üç yöntem varsa ortaya çıkar.

1. Eğer yazarsan

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

   ya da sadece yaz

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

   o olacak biter aynı yöntem haline yöntemde,

   public void ComplexOverloadResolution(params string[] something

   Bu, hiçbir parametre belirtilmediğindeparams de ondan en iyi eşleşmeyi sağlayan anahtar kelimenin nedenidir.

2. Bunun gibi yeni bir yöntem eklemeye çalışırsanız

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

   Bir parametreyle aramanız için mükemmel bir eşleşme olduğu için bu yöntemi mükemmel bir şekilde derleyecek ve çağıracaktır string. O zaman çok daha güçlü params string[] something.

3. Yaptığın gibi ikinci yöntemi ilan ediyorsun

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

   Derleyici, ilk yöntem ile bu arasında tam bir kafa karışıklığı içinde atlar, sadece bir tane ekledi. Çünkü şimdi aramanızın hangi işlevi yapması gerektiğini bilmiyor

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

   Aslında, aşağıdaki kod gibi, çağrıdan string parametresini kaldırırsanız, her şey doğru bir şekilde derlenir ve eskisi gibi çalışır.

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