C# da la bienvenida a los tipos unión en noviembre: un paso atrás que acerca el lenguaje a F# y Rust

Microsoft confirma a través de The Register la llegada de los tipos unión en C# en noviembre de 2026. Una funcionalidad que TypeScript, Rust, Swift y F# tienen desde hace mucho tiempo, y que cambia la forma de modelar los estados de negocio en C#.

El caso concreto

¿Cuántas veces hemos escrito este tipo de código en C# para representar un estado que puede tomar tres formas distintas?

public class ResultadoPago
{
 public bool EsExito { get; set; }
 public string? IdTransaccion { get; set; }
 public bool EstaPendiente { get; set; }
 public string? RazonPendiente { get; set; }
 public bool EsError { get; set; }
 public string? CodigoError { get; set; }
 public string? MensajeError { get; set; }
}

Un objeto donde tres booleanos se excluyen mutuamente, cinco campos nulos que solo tienen sentido en combinación con un booleano preciso, y cero garantías del compilador de que no olvidemos un caso en el if/else. Bienvenidos a la modelización por convención, que se basa en la disciplina del desarrollador, es decir, no en mucho.

Lo que ocurre

The Register anuncia el 2 de septiembre de 2026 que Microsoft ha confirmado la llegada de los tipos unión —también llamados «uniones discriminadas» o «sum types»— en C# en noviembre de 2026.

La idea es simple: en lugar de un objeto con cinco campos que «puede ser un éxito, una espera o un error», declaramos explícitamente al compilador que el tipo es uno de tres casos mutuamente excluyentes, cada uno con sus propios campos relevantes.

En pseudo-C# (la sintaxis final se anunciará oficialmente):

public union ResultadoPago
{
 Exito(string IdTransaccion);
 Pendiente(string Razon);
 Error(string Codigo, string Mensaje);
}

// Uso
switch (resultado)
{
 case ResultadoPago.Exito e:
 Console.WriteLine($"Transacción {e.IdTransaccion}");
 break;
 case ResultadoPago.Pendiente p:
 Console.WriteLine($"En espera: {p.Razon}");
 break;
 case ResultadoPago.Error err:
 Console.WriteLine($"Error {err.Codigo}: {err.Mensaje}");
 break;
 // El compilador notificará si falta un caso
}

El compilador verifica la exhaustividad del switch: olvidar un caso se convierte en un error, no en un bug de producción encontrado seis meses después.

Por qué es significativo

F#, primo funcional de C# en el mismo ecosistema .NET, tiene las uniones discriminadas desde siempre —es uno de los argumentos de venta históricos del lenguaje. Rust las ha convertido en un pilar de su diseño (los famosos enum y el match). Swift también. TypeScript, a su manera, tiene los tipos unión desde 2015. Kotlin tiene las sealed class que se acercan al patrón. C# llegaba con retraso —había que ingeniárselas con jerarquías de clases abstractas, sealed record, OneOf<T1,T2,T3> en bibliotecas de terceros.

Tres consecuencias concretas de esta llegada:

1. La modelización del negocio se vuelve más honesta. Los estados mutuamente excluyentes que representábamos por convención se convierten en tipos. El compilador se convierte en un aliado para no olvidar nada.
2. Las bibliotecas como OneOf y LanguageExt se reorganizarán. Parte de lo que ofrecían se vuelve nativo; el resto (monadas, aplicación parcial) sigue siendo útil.
3. La frontera C#/F# se difumina aún más. F# mantendrá sus ventajas (inferencia de tipos más avanzada, pipeline |>, inmutabilidad por defecto), pero la brecha se reduce: la elección del lenguaje en un proyecto .NET se plantea de forma distinta.

Qué hay que verificar antes de lanzarse

• La sintaxis definitiva: Microsoft aún no ha publicado la especificación final. Los ejemplos anteriores son ilustrativos.
• La interoperabilidad: cómo las uniones de C# se serializan en JSON, se comportan en Entity Framework, se exponen en WCF/gRPC. Estos detalles determinarán su adopción real.
• La compatibilidad: las uniones probablemente llegarán en C# 14+ con .NET 10. Los proyectos en .NET Framework históricos o .NET 8 LTS tendrán que esperar.

Para recordar

Los tipos unión en C#, es F# que se infiltra en C# —la línea editorial de Mads Torgersen (líder de diseño de C#) desde hace algunas versiones. Para nuestros proyectos, el interés más inmediato es la modelización de resultados de API (éxito/error/parcial), de estados de flujo de trabajo (borrador/en revisión/publicado), y de cargas polimórficas (event sourcing, mensajes Kafka).

No es revolucionario —otros lenguajes importantes lo tienen desde hace 10 años—. Pero para el ecosistema .NET empresarial, donde C# sigue siendo el lenguaje dominante en la lógica de negocio, es un salto cualitativo en la fiabilidad del tipado. A probar desde la vista previa de noviembre.