Tipizzazione implicita; perché solo variabili locali?

Question

Qualcuno sa o si preoccupa di speculare sul motivo per cui la digitazione implicita è limitata alle variabili locali?

var thingy = new Foo(); 

Ma perché non ...

var getFoo() { 
    return new Foo(); 
} 

Answer 1

Eric Lippert ha fatto un intero post sul blog sull'argomento.

• http://blogs.msdn.com/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx

In sintesi, il problema principale è che avrebbe richiesto un importante ri-architettura del compilatore C# per farlo. Le dichiarazioni vengono attualmente elaborate in un unico passaggio. Ciò richiederebbe più passaggi a causa della possibilità di creare cicli tra variabili dedotte. VB.net ha grosso modo lo stesso problema.

Answer 2

Penso che sia perché la portata di tale tipo implicita è molto più ampia e quindi più probabilità di causare problemi rispetto nell'ambito di un unico metodo.

Answer 3

Perché è molto più facile da fare. Se dovessi dedurre tutti i tipi, occorrerebbe qualcosa come il sistema di inferenza di tipo Hindley Milner che renderà il tuo amato C# nel linguaggio derivato Haskel.

Answer 4

In sostanza, il problema si esegue in è che C# (finora) è un linguaggio a tipizzazione statica. Una variabile locale definita come var è ancora tipizzata staticamente, ma sintatticamente nascosta. Un metodo che restituisce var, d'altra parte, ha molte implicazioni. Diventa più un'interfaccia per l'utilizzo e non si guadagna nulla usando var.

Answer 5

Jared ha una fantastica link nella sua risposta, ad un argomento fantastico.

penso che non risponde alla domanda in modo esplicito.

Perché no?

var getFoo() { 
    return new Foo(); 
} 

La ragione di questo è:

What if?

class Foo {} 

var GetFoo() { 
    return GetBar(); 
} 

var GetBar() { 
    return GetBaz(); 
} 

var GetBaz() { 
    return new Foo(); 
} 

Si potrebbe dedurre che GetFoo sta per tornare Foo, ma si dovrà tracciare attraverso tutti le chiamate che il metodo fa e le sue bambini fa solo per dedurre il tipo. Così com'è, il compilatore C# non è progettato per funzionare in questo modo. Ha bisogno di metodi e tipi di campo nelle prime fasi del processo prima del codice che può essere utilizzato dai tipi.

Su un piano puramente estetico trovo le definizioni var sui metodi di confondere le cose. Il suo unico posto dove penso che sia esplicito sempre aiuta, ti protegge dal spararti nel piede restituendo per sbaglio un tipo che causa la tua firma e una tonnellata di altre firme del metodo dipendente da modificare. Peggio ancora, potresti potenzialmente cambiare tutte le firme di una catena di metodi senza nemmeno sapere che lo hai fatto se restituisci il valore di un metodo che restituisce un oggetto e che è stato fortunato.

Penso metodi var è meglio lasciarle per linguaggi dinamici come Ruby

Answer 6

è possibile utilizzare in vs 2010 dinamica

Dynamic getFoo() { 
    return new Foo(); 
}