C# 8 - Tipos de Referência Anuláveis

A Microsoft está adicionando um novo recurso ao C# 8 chamado Tipos de Referência Anuláveis. O que, a princípio, é confuso porque todos os tipos de referência são anuláveis… então como isso é diferente? A partir de agora, se o recurso estiver habilitado, os tipos de referência são não-anuláveis, a menos que você os notifique explicitamente como anuláveis.

Deixe-me explicar.

Tipos de Referência Anuláveis

Quando os Tipos de Referência Anuláveis estão habilitados e o compilador acredita que um tipo de referência tem o potencial de ser nulo, ele avisa você. Você verá mensagens de aviso do Visual Studio:

E avisos de compilação:

Para remover este aviso, adicione um ponto de interrogação após o tipo de referência. Por exemplo:

public string StringTest()
{
    string? notNull = null;
    return notNull;
}

Agora o tipo de referência se comporta como fazia antes do C# 8.

Este recurso é habilitado adicionando <span class="inline-code"> #nullable enable </span> no topo de qualquer arquivo C# ou adicionando <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> ao arquivo .csproj. Por padrão, não está habilitado, o que é uma coisa boa porque se estivesse habilitado, qualquer base de código existente provavelmente brilharia como uma árvore de Natal.

O Debate sobre Nulo

Por que a Microsoft está adicionando este recurso agora? Os nulos fazem parte da linguagem desde, bem, o início? Honestamente, não sei por quê. Sempre usei nulos, é um fato da vida em C#. Não percebi que não ter nulos era uma opção… Talvez a vida seja melhor sem eles. Vamos descobrir.

Você deve ou não deve usar nulos? Resumo o debate contínuo conforme o entendo.

A Favor

O argumento a favor dos nulos é geralmente que um objeto tem um estado desconhecido. Este estado desconhecido é representado com nulo. Você vê isso com o tipo de dados bit no SQL Server, que tem 3 valores, nulo (não definido), 0 e 1. Você também vê isso em interfaces de usuário, onde às vezes é importante saber se um usuário tocou em um campo ou não. Alguém pode contra-argumentar: “Em vez de nulo, por que não criar um tipo de estado desconhecido ou um estado ‘não definido’?” Como isso é diferente de nulo? Você ainda teria que verificar este estado adicional. Agora você está criando estados desconhecidos para cada instância. Por que não apenas usar nulo e ter um estado desconhecido global?

Contra

O argumento contra os nulos é que é um tipo de dados diferente e deve ser verificado cada vez que você usa um tipo de referência. O resultado líquido é código como este:

var user = GetUser(username, password);

if(user != null)
{
    DoSomethingWithUser(user);
} else 
{
    SetUserNotFoundErrorMessage()
}

Se o método GetUser retornasse um usuário em todos os casos, inclusive quando o usuário não é encontrado. Se o código nunca retorna nulo, então é um desperdício se proteger contra isso e idealmente, isso simplifica o código. No entanto, em algum momento, você precisará verificar um usuário vazio e exibir uma mensagem de erro. Não usar um nulo não remove a necessidade de preencher o caso de negócio de um usuário não encontrado.

Isso é uma Boa Ideia?

O propósito deste recurso NÃO é eliminar o uso de nulos, mas sim fazer a pergunta: “Existe uma maneira melhor?” E às vezes a resposta é “Não”. Se conseguirmos eliminar a verificação constante de nulos com um pouco de previsão, o que por sua vez simplifica nosso código. Estou dentro. A boa notícia é que C# tornou o trabalho com nulos trivial.

Temo que alguns adotem uma postura dogmática e insistam em eliminar nulos em detrimento de um sistema. Isso é uma tarefa fútil, porque os nulos são integrais ao C#.

Tipos de Referência Anuláveis é uma boa ideia? É, se o resultado final for código mais simples e menos propenso a erros.