2010-11-09 11 views

Respuesta

12

Creo que se debe en parte al diseño del compilador. Eric Lippert blogged acerca de por qué campos no se puede usar el tipado implícito, y sospecho que algunos de los mismos argumentos son válidos para los métodos.

Pero podría terminar fácilmente con la ambigüedad de todos modos. Por ejemplo:

var Method1(bool callMethod2) 
{ 
    return callMethod2 ? Method2() : null; 
} 

var Method2() 
{ 
    return Method1(false); 
} 

¿Cuál debe ser el tipo aquí?

Un ejemplo más sencillo:

var Method1(bool throwException) 
{ 
    if (!throwException) 
    { 
     return Method1(true); 
    } 
    throw new Exception("Bang!"); 
} 

Es cierto que este tipo de ambigüedad podría simplemente ser rechazado, pero sospechoso que el equipo de diseño sentí que la complejidad añadida de diseño y puesta en práctica no valía la pena el beneficio . No se olvide de que se están ejecutando con recursos limitados, dada una opción entre var para métodos y async/await, elegiría este último en un abrir y cerrar de ojos. (Es cierto que hay otras características que yo hubiera escogido en lugar de dynamic, pero eso es otra cuestión ...)

Tenga en cuenta que la inferencia de tipos volver es realizado por las expresiones lambda, por lo que la misma idea de que no es loca. Por ejemplo:

IEnumerable<string> x = new[] { "x", "y", "z" }; 

var result = x.Select(s => { return s.Length; }); // Long form 

Allí, el compilador infiere el tipo completo de la expresión lambda cuando se realiza la resolución de sobrecarga en Select, convirtiéndolo en un Func<string, int>. No es inconcebible aplicar las mismas ideas a los métodos, simplemente complicado.

+4

Su análisis es, como de costumbre, perfecto. Hacer esta función correcta requiere * análisis completo del programa *, que tiene importantes impactos arquitectónicos y de rendimiento en el compilador. Además, se aplican todas las razones para "no var on fields". Por ejemplo, que no tenemos una forma estandarizada para representar un tipo anónimo en una API pública. Si desea un lenguaje que ofrezca este tipo de inferencia de tipo, intente con F #. –

2

var NO es un tipo de datos en C#. Es por eso que no puede usarlo como un parámetro de retorno. El compilador deduce el tipo en el momento de la compilación desde la mano derecha de la tarea y teniendo en cuenta que es conocido en tiempo de compilación que necesita utilizar el tipo real como valor de retorno. En C# 4.0 se puede utilizar el tipo dynamic:

public dynamic myFunction() 
{ 
    var = some operations 
} 
+0

-1, porque lo que se propone es simplemente que el compilador debe inferir cuál es el tipo de retorno real ... haciendo una declaración que usa 'var' equivalente a la misma declaración de método con un tipo de retorno explícito, inferido de las declaraciones de retorno dentro el cuerpo del método. No es inconcebible, simplemente complicado. Tenga en cuenta que ya está hecho para expresiones lambda, según el ejemplo en mi respuesta. –

-2

Yo creo que podría estropear la sobrecarga de métodos reglas.

Cuestiones relacionadas