C++26 falla su votación ISO: 12 de 20 votos a favor

C++26 no supera su votación DIS: 12 de 20 votos a favor

C++26 no logró la aprobación en su votación de Draft International Standard (DIS) y se convierte en el primer borrador de C++ que falla ese paso. El resultado, difundido por Robert Seacord, convenor del comité de C, fue de 12 votos a favor sobre 20 (60%) cuando se exigían dos tercios, y de 9 votos negativos sobre 22 (41%) cuando el techo era del 25%. La votación cerró el 23 de octubre de 2026.

Para cualquier startup con C++ en el corazón de su producto —infraestructura de datos, motores de trading, videojuegos, sistemas embebidos— la consecuencia es concreta: la versión del estándar que su equipo ya compila con -std=c++26 no tiene fecha de aprobación, y todavía nadie sabe cuánto se va a retrasar.

Seacord escribió que no cree que ningún estándar de lenguaje de SC22 haya fallado antes su votación. Daveed Vandevoorde, miembro del WG21 Direction Group (P5000R1), señaló que ningún borrador anterior de C++ había recibido ni un solo voto en contra. Reflection, std::execution, library hardening y contracts quedan dentro de un borrador que ISO no aprobó.

¿Qué condiciones tiene que cumplir un DIS?

Un Draft International Standard tiene que superar dos umbrales simultáneos, y el borrador de C++26 falló los dos:

• Votos a favor de los miembros votantes (P-members): al menos dos tercios. Resultado: 12 de 20, un 60%.
• Votos negativos de todos los organismos que votaron: no más del 25%. Resultado: 9 de 22, un 41%.

Dos tercios de 20 exigen 14 votos a favor, y el borrador obtuvo 12. Un cuarto de 22 permite cinco votos negativos, y el borrador obtuvo nueve. Cualquiera de las dos condiciones, por sí sola, habría bastado para rechazarlo.

¿Qué países votaron en contra?

Nueve países votaron No: Dinamarca, Finlandia, Irán, Italia, Japón, Luxemburgo, Rumanía, España y Suecia. Cada uno acompañó su voto con comentarios. Francia e Irlanda se abstuvieron pero también enviaron comentarios, de modo que 11 países comentaron en total. Polonia y Estados Unidos se abstuvieron.

Los comentarios todavía no son públicos. Las Directivas ISO/IEC (cláusula 2.6.5 de la Parte 1) obligan a publicar un informe completo dentro de las 12 semanas posteriores al cierre de la votación, con el resultado, la decisión del presidente del comité y el texto íntegro de los comentarios. Para una votación cerrada el 23 de octubre, eso es mediados de enero de 2027 como fecha límite. En la etapa de committee draft, WG21 publicó ese tipo de informe como N5028.

¿Por qué el conflicto es por los contracts?

El autor del análisis, miembro del organismo nacional polaco, sostiene que los nueve No fueron por contracts. Ambas objeciones presentadas en el plenario de Croydon que envió C++26 a votación eran sobre contracts, y varios comentarios de organismos nacionales al committee draft pidieron eliminarlos. El documento P4238R1 pidió explícitamente a los organismos nacionales votar No por el diseño de contracts y por cómo avanzó dentro del comité.

Un contract es una precondición o postcondición escrita en la propia firma de la función:

#include <cmath>
double checked_sqrt(double x)
    pre (x >= 0.0)
    post (r : r >= 0.0)
{
  const double root = std::sqrt(x);
  contract_assert(!std::isnan(root));
  return root;
}

El código no decide si cada verificación se ejecuta ni qué pasa cuando falla. El borrador define cuatro semánticas de evaluación —ignore, observe, enforce y quick-enforce— y deja la elección en manos de la implementación. En GCC 16 se elige con una bandera del compilador. Buena parte de la disputa es exactamente eso: si una aserción de contract es una verificación que el build puede descartar o una garantía sobre la que el programa puede confiar.

Seacord defiende la idea por dos ejes. El primero es la verificación: el programa puede comprobar sus propias suposiciones. El segundo, que le importa igual, es la documentación: una precondición en la firma registra la intención del diseñador de la API, y sistemas como Doxygen o cppreference.com pueden mostrarla ahí mismo. Un comentario puede decir lo mismo, pero nada lo mantiene verdadero: se desactualiza sin que nadie lo note. Un contract es parte del código, el compilador lo verifica junto con la función y, cuando las comprobaciones están activas, una violación falla de forma ruidosa. Los concepts ya dan eso para los tipos que acepta una función, en tiempo de compilación; los contracts son la pieza que falta para los valores, en tiempo de ejecución.

¿Qué puede decidir ISO ahora?

Tras una votación DIS fallida, las directivas contemplan cuatro caminos:

• Circular un borrador de encuesta revisado, con una votación de ocho semanas en lugar de doce.
• Circular un committee draft revisado para recibir comentarios.
• Circularlo como draft technical specification.
• Cancelar el proyecto.

El presidente de SC22 elige uno de los tres primeros, en cooperación con la secretaría de SC22 y el convenor de WG21, y en consulta con la oficina central de ISO/IEC. Cancelar es el único camino que tiene que decidir SC22 en pleno. La parte de WG21 es atender los comentarios, recomendar un curso de acción y, si hace falta, preparar un borrador revisado.

La próxima reunión de WG21 es en Búzios, Brasil, del 16 al 21 de noviembre de 2026, la primera del comité completo después del resultado. Las opiniones están divididas. P4433R0 es una propuesta formal para buscar otra votación sin cambiar ni eliminar contracts, y pide a WG21 rechazar los comentarios que exijan su remoción salvo que aporten información técnica nueva, confirmándolo con una encuesta en Búzios. J. Daniel Garcia, coautor de P4238R1, escribió que la solución de corto plazo es simple: eliminar una feature problemática y el resto del estándar probablemente se apruebe. La recomendación de Vandevoorde es sacar contracts del borrador, con ajustes para conservar library hardening. Algunos comentarios previos de organismos nacionales pedían una especificación técnica o un white paper.

Hasta que se publique una nueva edición, el estándar vigente sigue siendo ISO/IEC 14882:2024 (C++23).

¿Qué significa esto para tu startup?

No hay que revertir nada todavía. Los compiladores implementan features del working draft y la votación no cambia lo que ya envían: GCC 16 acepta -std=c++26 y Clang tiene -std=c++2c. Pero conviene tener claro que lo que tu compilador implementa hoy es un borrador y puede no coincidir con el estándar publicado.

Acciones concretas:

• Trata contracts como experimental, no como base de arquitectura. GCC 16 los implementa dentro de su soporte experimental de C++26 y la implementación de Clang no se ha fusionado. Nadie puede prometer hoy que los vendors mantengan cada feature bajo esa bandera. Si tu diseño de API depende de precondiciones verificadas por el compilador, aísla esa dependencia detrás de una capa propia.
• Planifica el calendario con holgura. Si tu roadmap asume reflection, std::execution o library hardening en una versión estable del estándar, agrega un escenario donde eso se corre. El propio autor del análisis pide que, si contracts tiene que salir de C++26 para que el resto se publique, el resto no espere.
• Si alguien de tu equipo está en un comité nacional, que vote. Un caso concreto del artículo: días antes del cierre de la votación polaca faltaban votos para el quórum, y sin quórum no habría posición nacional. Parte de la lista había cambiado de trabajo y algunos correos rebotaron. Si un miembro ya no puede participar, pedir la baja de la lista de votantes es un gesto operativo: el quórum lo cuenta igual.

Conclusión

C++26 es el primer borrador de C++ que no pasa su votación DIS, y el motivo apunta a un solo feature: contracts. El calendario queda abierto hasta que SC22 elija un camino y WG21 se reúna en Búzios. Para un equipo que ya usa C++26 en producción, la lectura práctica es no deshacer nada y no apostar la arquitectura a lo que todavía es un borrador. La votación no cambió lo que tus compiladores compilan; cambió, eso sí, la certeza sobre cuándo eso será estándar.

No se encontraron datos adicionales verificables sobre esta votación fuera de la fuente original.

Fuentes

• The result of the C++26 DIS ballot (fuente original)