La votación que detuvo a C++26 en seco
El camino de C++26 hacia la estandarización se encontró con un obstáculo sin precedentes el 24 de octubre de 2026. El borrador no superó su votación de Borrador de Norma Internacional (DIS) de la ISO, marcando la primera vez que un estándar de C++ ha sido rechazado en esta etapa crítica. Esta votación de todo o nada requería que los organismos miembros aprobaran el borrador completo, no características individuales.
Los resultados de la votación fueron claros: entre los miembros participantes, solo el 60% (12 de 20) votó a favor, sin alcanzar la mayoría de dos tercios requerida. Además, 9 de los 22 organismos miembros votaron "No", superando el límite del 25% permitido para el rechazo, alcanzando un alarmante 41%. Esto no fue una cancelación de C++ ni un rechazo general a todas las características de C++26; fue un pulgar hacia abajo decisivo a todo el paquete, impulsado por profundos desacuerdos sobre una única propuesta polémica.
Este resultado confirma que los organismos nacionales no son meros sellos de goma. El rechazo significa que el estándar C++26, tal como fue redactado, no seguirá adelante. La comunidad se enfrenta ahora a la compleja tarea de reevaluar y revisar el borrador, lo que podría retrasar significativamente el lanzamiento.
Los Contracts se convirtieron en la característica que rompió el acuerdo
Los Contracts, las comprobaciones en tiempo de ejecución propuestas para C++26, se convirtieron en el punto de ruptura indiscutible. Esta característica, detallada en P2900, tenía como objetivo introducir precondiciones, postcondiciones y aserciones integradas directamente en el lenguaje, permitiendo a los desarrolladores especificar los estados y comportamientos esperados del programa.
Esto no fue una adición menor; solo los Contracts aumentaron el borrador del estándar en aproximadamente 56 páginas. La propuesta especificaba cuatro modos de evaluación definidos por la implementación: ignore, observe, enforce y quick-enforce. Esta flexibilidad, destinada a adaptarse a varios escenarios de despliegue, alimentó en cambio una oposición significativa.
Los críticos, incluido el creador de C++, Bjarne Stroustrup, vieron los Contracts como un diseño grande e incompleto plagado de peligros. Argumentaron que introducía una complejidad innecesaria, nuevas vías para el comportamiento indefinido y un defecto de diseño fundamental: comprobaciones en tiempo de ejecución que podrían ser (y probablemente serían) desactivadas en las compilaciones de producción. Esto, argumentaron, socavaba el principio central de C++ de coste cero y ofrecía una solución de los años 80 a un problema que se aborda mejor mediante el análisis estático moderno.
Por qué el creador de C++ se unió a la oposición
Bjarne Stroustrup, el creador de C++, no solo no le gustaban los Contracts; ayudó a liderar la carga en su contra. En agosto, Stroustrup y cuatro coautores — J. Daniel Garcia, Vinnie Falco, John Spicer y Ville Voutilainen — publicaron P4334R0, “P2900 Contracts' Fundamental Flaws.” Este documento calificó la propuesta como una “amenaza existencial para C++” y descartó su enfoque como un “enfoque de los años 80 que ignora unos 50 años de progreso”.
La división central del diseño es marcada. Los críticos, incluido Stroustrup, abogan por un análisis estático coherente y garantías de seguridad robustas, argumentando que las comprobaciones solo en tiempo de ejecución violan el principio de coste cero de C++ al ser eliminadas de las compilaciones de producción. También sostuvieron que la propuesta introducía nuevos riesgos de comportamiento indefinido y modelos de herencia no probados.
Los partidarios, sin embargo, ven los contratos en tiempo de ejecución como una herramienta práctica e inmediatamente útil para expresar y verificar suposiciones del programa, una característica necesaria para el desarrollo moderno. Para más información sobre la propuesta, consulte P2900: Contracts for C++.
El contraargumento a la preocupación de Stroustrup sobre el "zero-overhead" es igualmente convincente: un proceso de estandarización funcional debería examinar una propuesta tan profundamente, en lugar de aprobar automáticamente un compromiso de comité. El rechazo de C++26 demuestra que los organismos nacionales están prestando atención, asegurando que las nuevas características cumplan con el estándar más alto, incluso si esto retrasa el estándar. Esto no se trata solo de Contracts; se trata de la integridad de todo el proceso de estandarización.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El daño colateral y la próxima decisión
La naturaleza de "todo o nada" de la votación de C++26 significa que Contracts no fracasó solo; se llevó consigo a todo el estándar. Características muy esperadas, como static reflection y std::execution, ahora languidecen en el limbo. Este daño colateral es un trago amargo para una comunidad ansiosa por progresar.
Este estancamiento llega mientras C++ enfrenta un escrutinio creciente para mejorar la seguridad y fiabilidad del software. Lenguajes competidores como Rust y Swift ofrecen garantías de seguridad de memoria y modelos de concurrencia robustos, presionando al Comité de Estándares de C++ para evolucionar. La industria exige más que solo rendimiento; exige una corrección demostrable.
Ahora, el comité debe trazar un rumbo difícil. Las opciones incluyen revisar los comentarios nacionales y abordar las preocupaciones, o, más drásticamente, eliminar Contracts por completo para salvar el cronograma. Podría surgir un compromiso más limitado, pero el camino final y su cronograma siguen siendo profundamente inciertos. Esta votación demuestra que una sola característica puede, efectivamente, detenerlo todo.
Preguntas frecuentes
¿Por qué el borrador de C++26 falló en su votación ISO?
El borrador no alcanzó el umbral de aprobación requerido y superó la cuota permitida de votos negativos. El desacuerdo sobre la propuesta de Contracts fue visto ampliamente como la causa central.
¿Qué son los Contracts en C++?
Los Contracts son características del lenguaje propuestas para expresar precondiciones, postcondiciones y aserciones que pueden verificarse en tiempo de ejecución.
¿La votación rechazó todas las características de C++26?
La votación cubrió el borrador completo del estándar, por lo que el borrador falló en su conjunto. Las objeciones descritas en la fuente se centraron principalmente en Contracts, no en todas las características de C++26.
¿Qué sucede con C++26 después de la votación fallida?
El comité debe revisar los comentarios de los organismos nacionales y decidir si eliminar Contracts, revisar la propuesta o buscar otra ruta. El cronograma de lanzamiento es incierto.