C# recebe tipos união em novembro - um retrocesso que aproxima a linguagem de F# e Rust

A Microsoft confirma, via o The Register, a chegada dos tipos união em C# em novembro de 2026. Uma funcionalidade que TypeScript, Rust, Swift e F# já possuem há muito tempo e que muda a forma de modelar estados de negócios em C#.

O caso concreto

Quantas vezes já escrevemos esse tipo de código em C# para representar um estado que pode assumir três formas distintas?

public class ResultadoPagamento
{
 public bool EhSucesso { get; set; }
 public string? IdTransacao { get; set; }
 public bool EstaEmEspera { get; set; }
 public string? RazaoEspera { get; set; }
 public bool HaErro { get; set; }
 public string? CodigoErro { get; set; }
 public string? MensagemErro { get; set; }
}

Um objeto onde três booleanos se excluem mutuamente, cinco campos nulos que só fazem sentido em combinação com um booleano específico, e nenhuma garantia do compilador de que não esqueceremos um caso no if/else. Bem-vindo à modelagem por convenção, que depende da disciplina do desenvolvedor — ou seja, não é lá grande coisa.

O que está acontecendo

O The Register anunciou em 2 de setembro de 2026 que a Microsoft confirmou a chegada dos tipos união — também chamados de «discriminated unions» ou «sum types» — no C# em novembro de 2026.

A ideia é simples: em vez de um objeto com cinco campos que «pode ser um sucesso, uma espera ou um erro», declaramos explicitamente ao compilador que o tipo é um de três casos mutuamente exclusivos, cada um com seus próprios campos relevantes.

Em pseudo-C# (a sintaxe final será anunciada oficialmente):

public union ResultadoPagamento
{
 Sucesso(string IdTransacao);
 Espera(string Razao);
 Erro(string Codigo, string Mensagem);
}

// Uso
switch (resultado)
{
 case ResultadoPagamento.Sucesso s:
 Console.WriteLine($"Transação {s.IdTransacao}");
 break;
 case ResultadoPagamento.Espera a:
 Console.WriteLine($"Em espera: {a.Razao}");
 break;
 case ResultadoPagamento.Erro e:
 Console.WriteLine($"Erro {e.Codigo}: {e.Mensagem}");
 break;
 // O compilador sinalizará se um caso estiver faltando
}

O compilador verifica a exaustividade do switch: esquecer um caso se tornará um erro, não um bug de produção descoberto seis meses depois.

Por que isso é significativo

O F#, primo funcional do C# no mesmo ecossistema .NET, tem as discriminated unions desde sempre — é um dos argumentos de venda históricos da linguagem. O Rust as tornou um pilar de seu design (os famosos enum e o match). O Swift também. O TypeScript, à sua maneira, tem os union types desde 2015. O Kotlin tem as sealed class que se aproximam do padrão. O C# chegava atrasado — era preciso improvisar hierarquias de classes abstratas, sealed record, ou bibliotecas de terceiros como OneOf<T1,T2,T3>.

Três consequências concretas dessa chegada:

1. A modelagem de negócios se torna mais honesta. Os estados mutuamente exclusivos que representávamos por convenção agora são tipos. O compilador se torna um aliado para não esquecermos de nada.
2. Bibliotecas como OneOf e LanguageExt serão reorganizadas. Parte do que elas ofereciam agora é nativa; o restante (monads, aplicação parcial) continua útil.
3. A fronteira C#/F# fica ainda mais turva. O F# manterá seus pontos fortes (inferência de tipo mais avançada, pipeline |>, imutabilidade por padrão), mas a lacuna se reduz — a escolha de linguagem em um projeto .NET passa a ser uma questão diferente.

O que verificar antes de adotar

• A sintaxe definitiva: a Microsoft ainda não publicou a especificação final. Os exemplos acima são ilustrativos.
• Interoperabilidade: como as uniões do C# são serializadas em JSON, se comportam no Entity Framework, ou são expostas em WCF/gRPC. Esses detalhes determinarão sua adoção real.
• Compatibilidade: as uniões provavelmente chegarão no C# 14+ com o .NET 10. Projetos em .NET Framework legados ou .NET 8 LTS terão que esperar.

Para lembrar

Os tipos união no C# são o F# infundindo no C# — a linha editorial de Mads Torgersen (líder de design do C#) há algumas versões. Para nossos projetos, o interesse mais imediato é a modelagem de resultados de API (sucesso/erro/parcial), estados de workflow (rascunho/em revisão/publicado), e payloads polimórficos (event sourcing, mensagens Kafka).

Não é revolucionário — outras linguagens importantes já o têm há 10 anos. Mas para o ecossistema .NET empresarial, onde o C# continua sendo a linguagem dominante em lógica de negócios, é um salto qualitativo na confiabilidade da tipagem. Vale a pena testar assim que a preview chegar em novembro.