Desde o beta do .NET, os desenvolvedores vêm solicitando a inclusão de variáveis não-anuláveis com semântica de referência. Mas o problema é bem mais complexo do que simplesmente inserir um atributo ou anotação. Craig Gidney, da Twisted Oaks Studios, propõe algumas soluções:
Se valores inesperados são o problema, devemos nos empenhar para eliminá-los. Valores nulos quase nunca são esperados, mas o sistema de tipagem nos obriga a agir como se fossem.
De uma forma ou de outra, o mesmo tem sido defendido por muitos desenvolvedores .NET ao longo dos anos. Mas a solução não é simples. Um dos maiores desafios é lidar com default<T>, onde T é um tipo de referência não-nulo. Craig Gidney diz:
O problema fundamental é um pressuposto muito arraigado em C#: que todo tipo possui um valor default. Pense: se T não tem (ou não pode ter) um valor default, então o compilador não tem o que usar quando avalia default (T), inicializa um campo do tipo T, ou inicializa itens em um novo array de T. Isso é problemático especialmente com tipos de referência não-nulos. Isso porque, embora alguns tipos de referência possuam um valor default não-nulo adequado (ex.: o valor default não-nulo de String poderia ser uma string vazia), a maioria não possui. Agora pense: qual é o valor default não-nulo de IEnumerator<int>? Seria IObservable<bool>? Ou UserControl? NetworkStream? A resposta simples é que não há um valor padrão não nulo. O "melhor" que se pode fazer é criar uma instância de uma classe que imita a classe original, e que gera um erro quando se tentar usá-la... Mas isso já temos, e se chama nulo.
No seu artigo Non-Nullable vs C#: Fixing the Billion Dollar Mistake (Tipos não-anuláveis e C#: consertando o erro de bilhões de dólares), Craig Gidney apresenta dois novos conceitos:
- T! para indicar que o tipo T é não-nulo, usado tanto em tipos normais quanto em parâmetros de tipo;
- withDefault(T), que transforma parâmetros de tipo de referência não-anuláveis em seus correspondentes anuláveis.
Se for preciso criar um campo ou array privado, pode-se usar withdefault(T) em vez do tipo T. Depois, ao ler o campo ou array, converte-se de volta para o tipo T não-anulável. Essa conversão em si é não-segura, pois pode provocar exceção se construída de modo inadequado, mas os desenvolvedores têm a garantia de que tudo o que estiver depois daquele ponto será não-anulável. As consequências disso são melhor explicadas pelos exemplos do artigo de Craig.
Se o leitor estiver interessado, pode votar na proposta de tipos de referência não-anuláveis no UserVoice.