2010-11-09 20 views

risposta

12

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.

+4

L'analisi è, come al solito, azzeccata. Fare questa funzione richiede * analisi dell'intero programma *, che ha importanti impatti architettonici e prestazionali sul compilatore. Inoltre, si applicano tutti i motivi per "nessun var sui campi". Ad esempio, non abbiamo un modo standardizzato per rappresentare un tipo anonimo in un'API pubblica. Se vuoi un linguaggio che offra questo tipo di inferenza di tipo, prova F #. –

2

var NON è un tipo di dati in C#. Ecco perché non puoi usarlo come parametro di ritorno. Il compilatore deduce il tipo in fase di compilazione dal lato destro del compito e tenendo presente che è noto al momento della compilazione che è necessario utilizzare il tipo reale come valore di ritorno. In C# 4.0 è possibile utilizzare il tipo di dynamic:

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

-1, perché ciò che viene proposto è semplicemente che il compilatore deve inferire qual è il vero tipo di ritorno ... facendo una dichiarazione che usa 'var' equivalente alla stessa dichiarazione di metodo con un tipo di ritorno esplicito, dedotto dalle dichiarazioni di ritorno all'interno il corpo del metodo. Non è inconcepibile, solo complicato. Si noti che è già stato fatto per le espressioni lambda, come nell'esempio nella mia risposta. –

-2

Io penso che potrebbe rovinare il metodo sovraccarico regole.

Problemi correlati