C++26 no supera la votación de ISO: el pulso por Contracts retrasa el estándar

El estándar C++26 tiene ahora un problema que ningún borrador anterior había tenido: un rechazo en la votación de los organismos nacionales de ISO. El ballot del Draft International Standard (DIS) se cerró a finales de octubre con un resultado negativo. El 60 % de los miembros participantes (P-Members) votó a favor —12 de 20—, por debajo del 66,66 % exigido. Entre los organismos nacionales, 9 de 22 votaron en contra —un 41 %, frente al máximo del 25 %— y 12 se abstuvieron. Los dos porcentajes proceden de recuentos distintos, no de una única suma de votos. Es la primera vez que un borrador de C++ no supera esta etapa, según los miembros del comité que han documentado el resultado.

La causa principal es Contracts, el sistema de contratos que debía entrar en C++26 con la propuesta P2900. El comité lo había adoptado en febrero de 2025 por 100 votos a favor, 14 en contra y 12 abstenciones. En octubre de 2026, una minoría del propio comité y varios organismos nacionales han bloqueado el estándar completo. La reunión de WG21 en Búzios (Brasil), del 16 al 21 de noviembre, será el primer encuentro de todo el grupo desde el rechazo.

Qué son los contratos de C++26

Un contrato permite escribir en la propia función lo que espera recibir y lo que garantiza al salir. En la propuesta P2900, una función puede declarar pre (x >= 0) para una precondición y post (r : r >= 0) para una postcondición; dentro del cuerpo, contract_assert comprueba una condición. La idea es que el compilador y las herramientas vean esas condiciones sin depender de comentarios que se quedan obsoletos, y que el programa pueda detenerse o avisar cuando no se cumplen.

El detalle que ha encendido el conflicto es qué ocurre con esas comprobaciones al compilar. P2900 define cuatro semánticas de evaluación —ignore, observe, enforce y quick-enforce— y deja la elección a la implementación, normalmente mediante una opción del compilador. El código fuente no puede exigir por sí solo que una precondición se compruebe siempre. Para los críticos, eso convierte una promesa de seguridad en una sugerencia que el sistema de compilación puede desactivar. Para los defensores, es una forma pragmática de no imponer costes de ejecución a quien no los necesita.

La crítica de Stroustrup

Bjarne Stroustrup, creador de C++, firmó en agosto de 2026 el documento P4334R0 junto a J. Daniel Garcia, Vinnie Falco, John Spicer y Ville Voutilainen. Su diagnóstico es duro: «Los contratos y extensiones de P2900 pretenden cambiar la naturaleza de C++ y son una amenaza existencial para C++, añadiendo complejidad y lastre». El documento sostiene que la implementación es desordenada, que parte del diseño está desactualizado, que no se ha probado lo suficiente y que el mismo objetivo podría cubrirse con una biblioteca.

La crítica no es solo técnica. También cuestiona el proceso: según los firmantes, el diseño avanzó por votaciones sin resolver objeciones de fondo de implementadores y de algunos organismos nacionales. Del otro lado, el documento P4433R0, firmado por dieciséis partidarios de Contracts, pide a WG21 que no lo retire, que rechace las peticiones de eliminación sin información técnica nueva y que confirme ambas cosas con una votación en Búzios. Su argumento es que el diseño se ha debatido durante años, que ha obtenido mayorías repetidas y que sacarlo ahora no es una operación mecánica: la especificación de endurecimiento de la biblioteca está escrita en términos de contratos.

Qué puede pasar en Búzios

ISO no permite decidir el futuro del proyecto en una votación improvisada. Las directivas contemplan cuatro salidas: circular un borrador revisado con una votación de ocho semanas, volver a la fase de comité, publicar el contenido como especificación técnica o cancelar el proyecto. La persona que preside el subcomité SC22 elige entre las tres primeras, en coordinación con la secretaría, el convenor de WG21 y la oficina central de ISO. WG21 debe responder a los comentarios y recomendar un camino.

Los comentarios de los organismos nacionales no se publican de inmediato. El informe completo tiene un plazo de doce semanas desde el cierre de la votación, así que no se conocerá antes de mediados de enero de 2027. Eso deja a Búzios con una tarea inmediata —decidir qué recomienda el comité— y otra más lenta: reconstruir el consenso. Si se opta por retirar Contracts para salvar el resto del estándar, habrá que reescribir partes del borrador y separar el endurecimiento de la biblioteca. Si se opta por volver a votar sin cambios, hará falta convencer a varios países que ya dijeron no.

El resto de C++26 también está en juego

C++26 no es solo Contracts. El borrador incluye reflexión estática, std::execution, mejoras de la biblioteca y el endurecimiento de contenedores y algoritmos. Todo eso queda en el mismo paquete que no ha sido aprobado. Si Contracts sale, esas funciones podrían publicarse con el resto; si el conflicto se prolonga, se retrasan con él. La propia denominación «C++26» está en duda: si la edición se publica en 2027, el nombre formal sería ISO/IEC 14882:2027 y muchos podrían llamarla C++27. Hasta entonces, el estándar vigente sigue siendo ISO/IEC 14882:2024, conocido como C++23.

Qué significa para tu código hoy

La votación no cambia lo que los compiladores ya implementan. GCC 16 acepta -std=c++26 y ofrece Contracts como parte de su soporte experimental; Clang usa -std=c++2c y su implementación de contratos aún no se ha integrado. Si tu equipo ya escribe pre, post o contract_assert, está trabajando sobre un borrador que puede cambiar, no sobre una garantía del estándar publicado. No hay que deshacer nada, pero conviene fijar la versión del compilador y no presentar esas comprobaciones como una barrera de seguridad definitiva.

Para el resto del código, la recomendación es la habitual: mantener assert, analizadores estáticos y sanitizadores para lo que no puede fallar, y tratar las funciones nuevas como lo que son, características de un borrador. La demora no invalida la reflexión estática ni std::execution, pero sí pospone la fecha en la que se puede decir que forman parte de un estándar ISO.

Una crisis de gobernanza

El rechazo no se explica solo por una disputa técnica. C++ publica una nueva versión cada tres años y el tren de lanzamiento no espera: si una función no entra a tiempo, puede pasar otro trienio antes de que lo intente. Esa presión empuja al comité a cerrar funciones con mayorías ajustadas y a los opositores a llevar el conflicto a los organismos nacionales. El resultado es un estándar bloqueado por una minoría que, a su vez, se siente ignorada por la mayoría.

La comparación con Rust suele aparecer en esta conversación, y no es casual: la seguridad de memoria y la facilidad para escribir código incorrecto en C++ son un argumento recurrente. Contracts no resuelve ese problema por sí solo, pero forma parte de la misma pregunta: cuánta complejidad está dispuesto a aceptar el lenguaje para ser más seguro. Búzios no va a responder a esa pregunta en una semana. Lo que puede hacer es evitar que la respuesta se convierta en un estándar que nadie puede publicar.