Non Nullable Reference Types e Progetti di Ricerca
Sino alla versione 1.*, una forte distinzione fra tipi reference e tipi value era costituita dal concetto di nullabilità: un tipo value per definizione non poteva assumere valori null, e analogamente un tipo reference non prevedeva il concetto di non-nullabilità. In pratica, dato ad esempio un riferimento a System.String, qualsiasi accesso ai membri di istanza, che determina una dereferenziazione del riferimento stesso, se non controllata poteva provocare eccezioni a run-time (la famosa NullReferenceException, che poi è la faccina sorridente di una "vecchia" access violation).
La versione 2.0 introduce il concetto di NullableType, mettendo di fatto a disposizione quello che, in molti casi, un programmatore si era costruito a mano: è ora possibile dichiarare un tipo di valore "nullabile", assegnarvi null e verificare che un'istanza sia o meno nulla. C'è molta documentazione a riguardo, e probabilmente molti hanno già avuto modo si sperimentare questa nuova caratteristica in una delle versioni preliminari che MS ha rilasciato fino ad ora (siamo alla beta 2, inutile rimarcarlo ancora).
Facciamo due conti: tipi valore non nullabili (da sempre), tipi valore nullabili (v2.0), tipi reference nullabili (da sempre) ... e se uno volesse utilizzare un tipo reference non nullabile ? E' possibile garantire questo vincolo, e come ?
Alcune settimane fa, Cyrus ha pubblicato una serie di post (qui il primo) che illustrano come la necessità di avere a disposizione tipi reference non nullabili sia effettivamente percepita, ma non così semplice da realizzare dal punto di vista del framework.
Una proposta di implementazione viene da Spec#.
E' un progetto di ricerca interno a Microsoft, volto ad estendere le funzionalità del linguaggio C#. Tra le caratteristiche introdotte, oltre ai Non-Nullable types, c'è il supporto alle checked exceptions (stile Java, e oltre). Vi rimando a questo documento introduttivo per una panormaica più completa.
C# è nato ex-novo e si basa sulla esperienza di anni di sviluppo e perfezionamento dei linguaggi di programmazione OO. Non per niente molte persone, non solo i suoi detrattori, si divertono a trovare le similitudini con altri linguaggi (Java e C++ principalmente), e nascono i dibattiti sui motivi per i quali una caratteristica sia stata inclusa o esclusa dall'implementazione.
Sulle checked exceptions mi ricordo di aver letto alcune discussioni (putroppo non ricordo i link però :-)), la nullabilità dei tipi è un argomento che attira sempre vivaci botta e risposta.
E' interessante notare come Microsoft porti avanti lo sviluppo e l'inclusione delle caratteristiche non originariamente previste: molto è affidato ai progetti di ricerca.
I Generics sono stati studiati ed implementati dal progetto Gyro come estensione di Rotor, e probabilmente molte delle caratteristiche sviluppate sono poi entrate nel ramo ufficiale.
Spec# introduce i concetti di tipi non nullabili ed eccezioni checked, due dei punti maggiormete richiesti dagli sviluppatori.
Prendiamo Cw (C-Omega). Le innovazioni, in questo caso, sono forse di portata ancora maggiore.
Il supporto all'esecuzione asincrona fornisce una sintassi a mio giudizio elegantissima a molti problemi di programmazione concorrente, eliminando anche diverse fonti di errori.
L'avvicinamento di CTS, XML e dati relazionali, è, almeno nelle intenzioni, a dir poco rivoluzionario, e non è un caso che Anders Hejlsberg veda in questo settore (gestione dei dati) la direzione principale nello sviluppo della versione 3 del suo linguaggio (C#, appunto).
Insomma, credo che dai progetti di ricerca si possano evincere, per lo meno, molte delle tendenze future.
E credo sia una cosa estremamente positiva il fatto che Microsoft dia la possibilità di sperimentare, fin da ora, queste novità. Che sono, sì, in fase super-preliminare, ma probabilmente contengono il seme di qualcosa di molto più grosso.