2010-12-17 13 views

Respuesta

16

C# tiene un apoyo muy limitado para la tipificación de "estructural". En particular, no puede convertir de un delegado-tipo a otro simplemente porque sus declaraciones son similares.

De la especificación del lenguaje:

tipos de delegado en C# son equivalentes nombre, no sea estructuralmente equivalente . Específicamente, dos tipos de delegado diferentes que tienen las mismas listas de parámetros y tipo de retorno se consideran tipos diferentes de delegado .

Pruebe uno de:

// C# 2, 3, 4 (C# 1 doesn't come into it because of generics) 
BinaryOperation b1 = new BinaryOperation(addThem); 

// C# 3, 4 
BinaryOperation b1 = (x, y) => addThem(x, y); 
var b1 = new BinaryOperation(addThem); 
+0

Brilliant! ¡Gracias! (... Necesita esperar 11 minutos para marcar el suyo como la respuesta ...) – Hobbes

+12

La razón para el tipado no estructural es porque la definición de delegado puede tener semántica. No debería poder asignar un "Func" a un "SecureFunc", o un "PureFunc" o un "NoSideEffectsFunc" o lo que sea. En la práctica, nadie hace realmente tipos de delegados que tengan semántica; si tuviéramos que volver a hacerlo, los delegados probablemente tendrían una estructura más estructural. –

+0

@Eric Lippert: Es un punto interesante. ¿Cuál es su opinión sobre por qué hay tantos tipos de delegados "duplicados" con la misma "estructura" en el BCL, como Action, ThreadStart, MethodInvoker? – Ani

7

Aquí hay una pregunta similar: ¿por qué no esta compilar?

// declared somewhere 
struct Foo { 
    public int x; 
    public int y; 
} 

struct Bar { 
    public int x; 
    public int y; 
} 

// ... in a method body 
Foo item = new Foo { x = 1, y = 2 }; 

Bar b1 = item; // doesn't compile, and casting doesn't compile 
Bar b2 = new Bar { x = 1, y = 2 }; // compiles! 

En este caso, parece un poco más natural que el yeso no funcione, pero es realmente la misma razón.

Cuestiones relacionadas