Perché non T.TryParse restituisce un Nullable <T>

Question

Per quanto ne so, int.TryParse(string, out int) esiste dal Framework 2.0. Così fa int?.

C'è una ragione per usare un parametro out invece di restituire un int? con HasValue insieme a true di false a seconda della capacità di convertire?

Answer 1

Non posso dire circa i motivi reali, ma vedo tre possibili ragioni:

1) Nullable types sono state introdotte in .NET 2.0, mentre il first TryParse methods erano già in giro dal .NET 1.1.Pertanto, quando sono stati introdotti i tipi nullable, era troppo tardi per una tale modifica dell'API; e le nuove classi non implementerebbero TryParse in modo diverso perché il modello era già stato impostato.

2) Non tutti i tipi possono essere utilizzati con Nullable structure, solo i tipi di valori possono. Tuttavia, esistono metodi che seguono lo schema Try* che devono restituire tipi di riferimento. Ad esempio, un dizionario può legittimamente contenere null come un elemento, quindi il suo TryGetValue method richiede un ulteriore modo per esprimere che una chiave non è stata trovata.

3) Il modo in cui i Try* -metodi sono scritte, è possibile scrivere codice come questo:

int myValue; 
if (int.TryParse("42", out myValue)) { 
    // do something with myValue 
} 
    // do something else 
} 

Ora, immaginate se TryParse restituito solo un int?. È possibile disporre della variabile myValue e perdere il risultato:

if (int.TryParse("42").HasValue) { 
    // do something with ... what? You didn't store the conversion result! 
} 
    // do something else 
} 

Oppure è possibile aggiungere una variabile annullabile:

int? myValue = int.TryParse("42"); 
if (myValue.HasValue) { 
    // do something with myValue.Value 
} 
    // do something else 
} 

Questo non è un vantaggio rispetto alla versione attuale più, e invece richiede la scrittura di myValue.Value in alcune istanze successive, dove altrimenti sarebbe sufficiente un semplice value. Si noti che in molti casi, è sufficiente che solo richieda l'informazione sull'esito dell'operazione per l'istruzione if.

Answer 2

Per quanto riguarda motivi possiamo solo immaginare, ma alcuni possibili ragioni sono:

Assegnazione in testa: un valore boxed comporta qualche (piccolo) sovraccarico di prestazioni nel corso di un costruito in tipo.

No guadagni reali:

int res; 
if int.TryParse("one", out res) { 
    //something 
} 

non è molto peggio di

int? res = int.TryParse("one"); 
if (res.HasValue){ 
    int realres = res.Value 
    //something 
} 

Answer 3

Ecco una citazione dal blog di Julie Lerman (Ritorno dal 2004):

ho giocato con nullable nei bit di anteprima di marzo, ma non ancora nel maggio e deluso con la corrente (ma previsto per il miglioramento serio dal bcl team !!!) prestazioni quando ho confrontato l'utilizzo di nullable<t> sulle opzioni correnti. Così, per esempio con tipi di valore:

confrontando myNullableInt.HasValue a (in VB) è myInt < 0

o con tipi di riferimento

confrontando myNullableThing.HasValue a “if not myThing=null”

tipo nullable è attualmente molto molto più lento. Sono stato promesso da alcuni sul team BCL che il piano è quello di rendere il MOLTO più performante MUCH.

ho anche dato il suggerimento che, in futuro, di seguito sarà possibile:

Nullable<T> Parse(string value); 
Nullable<Int32> i = Int32.Parse(some String); 

e sarà più performante rispetto TryParse. Così anche questo sarà interessante.

mi assumo che, come sempre, i benefici superino i costi.

In ogni caso, nel prossimo C# vNext, si può fare:

DateTime.TryParse(s, out var parsedDateTime); 

Passando TryParse in un uno di linea.

Answer 4

Il semplice motivo è perché quando int.TryParse è stato aggiunto alla lingua, Nullable<T> non esisteva.

In this blog post by Eric Lippert, c'è una linea verso il fondo che recita:

La soluzione è quella di scrivere la propria versione metodo di estensione del TryParse il modo in cui sarebbe stato scritto se ci fosse stato tipi di valore nullable disponibili nel primo luogo

che chiarisce che tipi nullable non erano disponibili da utilizzare nell'implementazione originale di TryParse. Eric Lippert era nel team che ha scritto il compilatore C#, quindi direi che è una fonte piuttosto autorevole.

Answer 5

Un altro motivo possibile:

Generics per # .NET e C nella loro forma attuale quasi non è accaduto: era una chiamata molto vicino, e la caratteristica quasi non ha fatto il taglio per Whidbey (Visual Studio 2005). Funzionalità come l'esecuzione del codice CLR nel database hanno avuto maggiore priorità.

...

In ultima analisi, un modello cancellazione dei farmaci generici sarebbero state adottate, come per Java, in quanto la squadra CLR non avrebbe mai perseguito una VM in-generici di progettazione senza aiuto esterno.

fonte: http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-generics-history-some-photos-from-feb-1999.aspx

Il mio punto dell'essere: la maggior parte dei cambiamenti del BCL (o almeno quelli non direttamente legato alla generici) probabilmente necessaria per lavorare sia con e senza farmaci generici, in caso in cui la feature è stata tagliata nell'RTM finale.

Ovviamente, questo ha anche senso dal punto di vista del client di chiamata: tutti i linguaggi che consumano (ok, non ce n'erano molti allora) sarebbero stati idealmente in grado di usarli - e i parametri out non erano così taglienti come i generici.