Perché non è possibile assegnare un metodo anonimo a var?

Ho il codice seguente:

Func<string, bool> comparer = delegate(string value) {
    return value != "0";
};

Tuttavia, non viene compilato quanto segue:

var comparer = delegate(string value) {
    return value != "0";
};

Perché il compilatore non riesce a capire che è un Func<string, bool> ? Accetta un parametro stringa e restituisce un valore booleano. Invece, mi dà l'errore:

Impossibile assegnare il metodo anonimo a una variabile locale tipizzata in modo implicito.

Ho una supposizione e cioè se la versione var compilata , mancherebbe di coerenza se avessi il seguente:

var comparer = delegate(string arg1, string arg2, string arg3, string arg4, string arg5) {
    return false;
};

Quanto sopra non avrebbe senso poiché Func <> consente solo fino a 4 argomenti (in .NET 3.5, che è quello che sto usando). Forse qualcuno potrebbe chiarire il problema. Grazie.

Altri hanno già sottolineato che ci sono infiniti possibili tipi di delegati che potresti voler dire; cosa c'è di così speciale Funcche merita di essere il default invece di Predicateo Actiono qualsiasi altra possibilità? E, per Lambdas, perché è ovvio che l'intenzione è quella di scegliere la forma del delegato, piuttosto che la forma dell'albero delle espressioni?

Ma potremmo dire che Funcè speciale e che il tipo inferito di un lambda o un metodo anonimo è Func di qualcosa. Avremmo ancora tutti i tipi di problemi. Quali tipi desideri dedurre per i seguenti casi?

var x1 = (ref int y)=>123;

Non esiste un Func<T>tipo che accetta un ref.

var x2 = y=>123;

Non conosciamo il tipo di parametro formale, sebbene conosciamo il ritorno. (O noi? Il ritorno è int? Long? Short? Byte?)

var x3 = (int y)=>null;

Non conosciamo il tipo restituito, ma non può essere nullo. Il tipo restituito può essere qualsiasi tipo di riferimento o qualsiasi tipo di valore annullabile.

var x4 = (int y)=>{ throw new Exception(); }

Ancora una volta, non conosciamo il tipo restituito e questa volta può essere nullo.

var x5 = (int y)=> q += y;

Intende essere un'istruzione lambda che restituisce il vuoto o qualcosa che restituisce il valore assegnato a q? Entrambi sono legali; quale dovremmo scegliere?

Ora, potresti dire, beh, semplicemente non supportare nessuna di queste funzionalità. Supporta solo casi "normali" in cui è possibile elaborare i tipi. Questo non aiuta. In che modo mi semplifica la vita? Se la funzione funziona a volte e fallisce a volte, devo ancora scrivere il codice per rilevare tutte quelle situazioni di errore e dare un messaggio di errore significativo per ciascuna. Dobbiamo ancora specificare tutto quel comportamento, documentarlo, scrivere test per questo e così via. Questa è una funzione molto costosa che consente all'utente di salvare una mezza dozzina di tasti. Abbiamo modi migliori per aggiungere valore alla lingua piuttosto che passare molto tempo a scrivere casi di prova per una funzionalità che non funziona per metà del tempo e che non fornisce quasi alcun vantaggio nei casi in cui funziona.

La situazione in cui è effettivamente utile è:

var xAnon = (int y)=>new { Y = y };

perché non esiste un tipo "parlabile" per quella cosa. Ma abbiamo questo problema in ogni momento e usiamo solo l'inferenza del tipo di metodo per dedurne il tipo:

Func<A, R> WorkItOut<A, R>(Func<A, R> f) { return f; }
...
var xAnon = WorkItOut((int y)=>new { Y = y });

e ora l'inferenza del tipo di metodo determina quale sia il tipo di funzione.

Solo Eric Lippert lo sa per certo, ma penso che sia perché la firma del tipo delegato non determina in modo univoco il tipo.

Considera il tuo esempio:

var comparer = delegate(string value) { return value != "0"; };

Ecco due possibili inferenze per ciò che vardovrebbe essere:

Predicate<string> comparer  = delegate(string value) { return value != "0"; };  // okay
Func<string, bool> comparer = delegate(string value) { return value != "0"; };  // also okay

Quale dovrebbe dedurre il compilatore? Non c'è un buon motivo per scegliere l'uno o l'altro. E sebbene a Predicate<T>sia funzionalmente equivalente a a Func<T, bool>, sono comunque tipi diversi a livello del sistema di tipi .NET. Il compilatore pertanto non può risolvere in modo inequivocabile il tipo delegato e non deve inferire l'inferenza del tipo.

Eric Lippert ha un vecchio post a riguardo dove dice

E in effetti la specifica C # 2.0 lo chiama fuori. Le espressioni del gruppo di metodi e le espressioni di metodo anonime sono espressioni senza tipo in C # 2.0 e le espressioni lambda le uniscono in C # 3.0. Pertanto è illegale per loro apparire "nudi" sul lato destro di una dichiarazione implicita.

Diversi delegati sono considerati tipi diversi. ad esempio, Actionè diverso da MethodInvoker, e un'istanza di Actionnon può essere assegnata a una variabile di tipo MethodInvoker.

Quindi, dato un delegato anonimo (o lambda) come () => {}, è un Actiono un MethodInvoker? Il compilatore non può dirlo.

Allo stesso modo, se dichiaro un tipo di delegato prendendo un stringargomento e restituendo un bool, come farebbe il compilatore a sapere che volevi davvero un tipo al Func<string, bool>posto del mio delegato? Non può inferire il tipo delegato.

I seguenti punti provengono da MSDN per quanto riguarda le variabili locali tipizzate in modo implicito:

1. var può essere utilizzato solo quando una variabile locale viene dichiarata e inizializzata nella stessa istruzione; la variabile non può essere inizializzata su null, su un gruppo di metodi o su una funzione anonima.
2. La parola chiave var indica al compilatore di dedurre il tipo di variabile dall'espressione sul lato destro dell'istruzione di inizializzazione.
3. È importante comprendere che la parola chiave var non significa "variante" e non indica che la variabile è tipizzata in modo approssimativo o in ritardo. Significa solo che il compilatore determina e assegna il tipo più appropriato.

Riferimento MSDN: variabili locali tipizzate in modo implicito

Considerando quanto segue per quanto riguarda i metodi anonimi:

1. I metodi anonimi consentono di omettere l'elenco dei parametri.

Riferimento MSDN: metodi anonimi

Sospetto che dal momento che il metodo anonimo potrebbe effettivamente avere firme di metodi diversi, il compilatore non è in grado di inferire correttamente quale sarebbe il tipo più appropriato da assegnare.

Il mio post non risponde alla domanda reale, ma risponde alla domanda sottostante di:

"Come posso evitare di dover scrivere un tipo fugly come Func<string, string, int, CustomInputType, bool, ReturnType>?" ^[1]

Essendo il programmatore pigro / azzurrato che sono, ho sperimentato con l'uso Func<dynamic, object> - che accetta un singolo parametro di input e restituisce un oggetto.

Per più argomenti, puoi usarlo in questo modo:

dynamic myParams = new ExpandoObject();
myParams.arg0 = "whatever";
myParams.arg1 = 3;
Func<dynamic, object> y = (dynObj) =>
{
    return dynObj.arg0.ToUpper() + (dynObj.arg1 * 45); //screw type casting, amirite?
};
Console.WriteLine(y(myParams));

Suggerimento: è possibile utilizzare Action<dynamic> se non è necessario restituire un oggetto.

Sì, lo so che probabilmente va contro i tuoi principi di programmazione, ma questo ha senso per me e probabilmente per alcuni programmatori Python.

Sono piuttosto alle prime armi con i delegati ... volevo solo condividere ciò che ho imparato.

^[1] Ciò presuppone che tu non stia chiamando un metodo che richiede un predefinito Funccome parametro, nel qual caso dovrai digitare quella stringa fugly: /

Che ne dici?

var item = new
    {
        toolisn = 100,
        LangId = "ENG",
        toolPath = (Func<int, string, string>) delegate(int toolisn, string LangId)
        {
              var path = "/Content/Tool_" + toolisn + "_" + LangId + "/story.html";
              return File.Exists(Server.MapPath(path)) ? "<a style=\"vertical-align:super\" href=\"" + path + "\" target=\"_blank\">execute example</a> " : "";
        }
};

string result = item.toolPath(item.toolisn, item.LangId);