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.
Bueno, si no lo sabe, ¿cómo debe saber el compilador? – leppie