Appel ambigu entre deux méthodes génériques d'extension C# : l'une où T:class et l'autre où T:struct.

Question

Considérons deux méthodes d'extension :

public static T MyExtension<T>(this T o) where T:class
public static T MyExtension<T>(this T o) where T:struct

Et un cours :

class MyClass() { ... }

Maintenant, appelez la méthode d'extension sur une instance de la classe ci-dessus :

var o = new MyClass(...);
o.MyExtension(); //compiler error here..
o.MyExtension<MyClass>(); //tried this as well - still compiler error..

Le compilateur dit que l'appel de la méthode est un appel ambigu lorsque je l'appelle sur une classe. J'aurais pensé qu'il pouvait déterminer quelle méthode d'extension appeler, puisque MyClass est une classe et non un struct ?

Answer 1

EDIT : J'ai maintenant a publié un blog à ce sujet de manière plus détaillée.

---

Ma pensée initiale (et je pense maintenant qu'elle est incorrecte) : les contraintes génériques ne sont pas prises en compte pendant les phases de résolution des surcharges et d'inférence de type - elles ne sont utilisées que pour valider le résultat de la résolution des surcharges.

EDIT : Ok, après un lot d'aller et venir sur ce sujet, je pense que j'y suis. En gros, ma première pensée était presque correct.

Les contraintes de type générique n'agissent que pour supprimer les méthodes d'un ensemble de candidats dans un système de gestion de l'information. muy un ensemble limité de circonstances... en particulier, seulement lorsque le type d'un paramètre lui-même est générique ; pas seulement un paramètre de type, mais un type générique qui utilise un paramètre de type générique. À ce stade, ce sont les contraintes sur les paramètres de type du type générique qui sont validées, et non les contraintes sur les paramètres de type de la méthode générique que vous appelez.

Par exemple :

// Constraint won't be considered when building the candidate set
void Foo<T>(T value) where T : struct

// The constraint *we express* won't be considered when building the candidate
// set, but then constraint on Nullable<T> will
void Foo<T>(Nullable<T> value) where T : struct

Donc si vous essayez d'appeler Foo<object>(null) la méthode ci-dessus ne le fera pas faire partie de l'ensemble des candidats, car Nullable<object> value ne satisfait pas aux contraintes de Nullable<T> . S'il existe d'autres méthodes applicables, l'appel peut encore aboutir.

Maintenant, dans le cas ci-dessus, les contraintes sont exactement les mêmes... mais elles ne doivent pas l'être. Par exemple, considérons :

class Factory<TItem> where TItem : new()

void Foo<T>(Factory<T> factory) where T : struct

Si vous essayez d'appeler Foo<object>(null) la méthode fera toujours partie de l'ensemble des candidats, car lorsque l TItem es object la contrainte exprimée dans Factory<TItem> tient toujours, et c'est ce qui est vérifié lors de la construction de l'ensemble des candidats. Si cette méthode s'avère être la meilleure, elle échouera à la validation ultérieure, à proximité de l'option fin de 7.6.5.1 :

Si la meilleure méthode est une méthode générique, les arguments de type (fournis ou inférés) sont vérifiés par rapport aux contraintes (§4.4.4) déclarées sur la méthode générique. Si un argument de type ne satisfait pas la ou les contraintes correspondantes sur le paramètre de type, une erreur de liaison se produit.

Eric article de blog contient plus de détails à ce sujet.

Answer 2

Eric Lippert l'explique mieux que je ne le pourrais jamais, aquí .

J'ai moi-même rencontré ce problème. Ma solution était

public void DoSomthing<T> (T theThing){
    if (typeof (T).IsValueType)
        DoSomthingWithStruct (theThing);
    else
        DoSomthingWithClass (theThing);  
}

// edit - seems I just lived with boxing

public void DoSomthingWithStruct (object theThing)
public void DoSomthingWithClass(object theThing)

Answer 3

J'ai trouvé une façon étrange et "intéressante" de le faire dans .NET 4.5 en utilisant des valeurs de paramètres par défaut :) Peut-être que c'est plus utile pour l'éducation \speculative que pour une utilisation réelle mais je voudrais le montrer :

/// <summary>Special magic class that can be used to differentiate generic extension methods.</summary>
public class MagicValueType<TBase>
    where TBase : struct
{
}

/// <summary>Special magic class that can be used to differentiate generic extension methods.</summary>
public class MagicRefType<TBase>
    where TBase : class
{
}

struct MyClass1
{
}

class MyClass2
{
}

// Extensions
public static class Extensions
{
    // Rainbows and pink unicorns happens here.
    public static T Test<T>(this T t, MagicRefType<T> x = null)
        where T : class
    {
        Console.Write("1:" + t.ToString() + " ");
        return t;
    }

    // More magic, other pink unicorns and rainbows.
    public static T Test<T>(this T t, MagicValueType<T> x = null)
        where T : struct
    {
        Console.Write("2:" + t.ToString() + " ");
        return t;
    }
}

class Program
{
    static void Main(string[] args)
    {

        MyClass1 t1 = new MyClass1();
        MyClass2 t2 = new MyClass2();

        MyClass1 t1result = t1.Test();
        Console.WriteLine(t1result.ToString());

        MyClass2 t2result = t2.Test();
        Console.WriteLine(t2result.ToString());

        Console.ReadLine();
    }
}