Credo sia dovuto in parte al design del compilatore. Eric Lippert blogged sul motivo per cui i campi non possono utilizzare la digitazione implicita e sospetto che alcuni degli stessi argomenti valgano per i metodi.
Ma si potrebbe facilmente finire con l'ambiguità comunque. Ad esempio:
var Method1(bool callMethod2)
{
return callMethod2 ? Method2() : null;
}
var Method2()
{
return Method1(false);
}
Che tipo dovrebbe essere qui?
Un esempio più semplice:
var Method1(bool throwException)
{
if (!throwException)
{
return Method1(true);
}
throw new Exception("Bang!");
}
Evidentemente questo tipo di ambiguità potrebbe semplicemente essere annullato, ma io sospetto che il team di progettazione sentito che la complessità sia della progettazione e realizzazione non valeva il vantaggio . Non dimenticare che sono in esecuzione con risorse limitate - data una scelta tra var
per i metodi e async/await
, selezionerei quest'ultima in un istante. (Certo ci sono altre caratteristiche che avrei potuto scegliere, invece di dynamic
, ma questo è un altro discorso ...)
Nota che restituiscono l'inferenza dei tipi è eseguito per espressioni lambda, così l'idea stessa di esso non è pazza. Ad esempio:
IEnumerable<string> x = new[] { "x", "y", "z" };
var result = x.Select(s => { return s.Length; }); // Long form
C'è il compilatore deduce il tipo completo dell'espressione lambda quando esegue la risoluzione sovraccarico Select
, convertendolo in un Func<string, int>
. Non è inconcepibile applicare le stesse idee ai metodi, solo complicati.
fonte
2010-11-09 09:56:40
Bene, se non lo sai, come deve sapere il compilatore? – leppie