El operador de fusión y los tipos anulables

Los nuevos tipos anulables son tipos instanciados a partir del tipo genérico System.Nullable<T>. Este tipo genérico restringe los tipos aceptables para su argumento genérico T exigiendo que sean tipos de valor: es correcto usar Nullable<int>, pero no podemos usar Nullable<string>. No obstante, hay restricciones adicionales sui generis. Por ejemplo, aunque el propio Nullable está declarado como una estructura, un tipo cerrado basado en Nullable no se puede usar como parámetro del propio Nullable. Es decir, no podemos usar tipos como Nullable<Nullable<int>>.

Una instancia de Nullable<T> contiene un valor del tipo T, al que podemos acceder mediante la propiedad Value, y un valor de tipo lógico, al que accedemos mediante otra propiedad: HasValue. Sólo podemos acceder a Value cuando HasValue devuelve true; en caso contrario, la llamada a Value provoca una excepción.

Hay varias formas de interpretar estas reglas de juego. La más natural, como veremos, es ver en los tipos instanciados a partir de Nullable una forma muy útil y sencilla de simular los valores nulos con los que trabaja el lenguaje SQL. Enseguida veremos cómo esa interpretación se refuerza con la ayuda de otras características, como la compatibilidad para la asignación de punteros nulos y los llamados lifted operators.

Si hacemos caso al documento "oficial" de la documentación de C# 2.0 fechado en mayo del 2004 (al que todavía nos remite la MSDN en las navidades del 2005), sí se podrían declarar tipos anulables basados en otros tipos anulables. Es verdad que esto no aportaría nada en expresividad al lenguaje, pero no sé si es bueno haber creado una regla ad hoc para impedirlo... a no ser que se me escape alguna otra consecuencia indeseable. En todo caso, esta restricción se introdujo después de mayo del 2004.

En vez de escribir Nullable<DateTime>, podemos abreviar y escribir DateTime?, utilizando el signo de interrogación a continuación de la referencia de tipo. No se trata exactamente de una novedad revolucionaria, pero reconozcamos que es muy conveniente. En primer lugar, por la claridad que aporta. En segundo, por lo que nos ahorra en tiempo y espacio. Y en tercer lugar, porque hace más digerible la restricción de no declarar tipos como int??

Ya sé que acabo de escribir una herejía, y que cierto ministro amontillado me puede cerrar la página por ello... pero es que hablar de "referencias nulas" es estúpido, y qué demonios, null (o nil, en Freya) es en realidad un puntero vacío (¡qué manía tienen algunos de cambiarle el nombre a las cosas!).

Lo importante ahora es saber que podemos asignar null a una variable de un tipo anulable. Que yo sepa, no existe forma alguna de lograr esta compatibilidad con las reglas del sistema de tipos de C#, por lo que ésta sería una más entre las particularidades del tipo Nullable. Puede que en otros sistemas de tipos, una regla de esta especie sea más natural. Pongamos como caso el de Eiffel: en este lenguaje, el tipo object se llama ANY, y de él descienden por herencia las restantes clases. Pero existe otro tipo especial: VOID, que teóricamente tiene a todas las otras clases como ancestros (¡Eiffel soporta herencia múltiple!). El puntero nulo de Eiffel pertenece precisamente a esta clase especial. Si existiese un tipo parecido en el CLR, sería posible definir un operador de conversión implícita, del tipo VOID a cada una de las clases instanciadas a partir de Nullable.

Por supuesto, esta es una disgresión teórica. Desde el punto de vista práctico, lo importante es que podemos asignar null a cualquier variable o parámetro de tipo anulable.

Renuncio a traducir la frase. Está claro que lift quiere decir elevar, pero en este contexto es más probable que signifique promover. En todo caso, se trata de la semántica de los operadores aplicables al tipo base de un tipo anulable, que como es natural, cambia cuando se aplica a tipos anulables. Tomemos el siguiente fragmento de código en C# 2.0:

int? x = 1;
int? y = null;
int? z = x + y;

En la primera instrucción, asignamos un valor entero a una variable de tipo anulable. Hay una conversión implícita de un valor int al tipo int?. La segunda instrucción es posible gracias a la compatibilidad antes mencionada con el puntero nulo. En este caso, la propiedad HasValue aplicada a la variable y devolvería false. Si sumamos ambas variables, ¿qué es lo que debería contener la variable z? Si interpretamos los tipos anulables como si se tratase de columnas de una base de datos, cualquier operación que incluya al menos un valor nulo, debe dar nulo como resultado (la excepción son los operadores and y or). Pues bien, esto mismo es lo que ocurre con los tipos anulables. La mencionada suma se debe implementar de forma parecida a la siguiente:

if (x.HasValue && y.HasValue)
    z = x.Value + y.Value;
else
    z = null;

x ?? y

x.HasValue ? x.Value : y

if (interfaceList != null)
    this.interfaces = interfaceList;
else
    this.interfaces = new TypeSymbol[0];

this.interfaces = interfaceList != null ?
    interfaceList : new TypeSymbol[0];

this.interfaces = interfaceList ?? new TypeSymbol[0];