C++26 no supera la votación ISO por los Contracts, probado en GCC 16

El borrador de C++26, la próxima versión del estándar del lenguaje C++, no superó su votación ISO en octubre de 2026. La disputa que lo hizo caer gira en torno a una sola función: los Contracts. El comité de C++, llamado WG21, se reúne del 16 al 21 de noviembre en Búzios, Brasil. Allí decidirá si elimina la función, la traslada fuera o la vuelve a votar. El resultado decidirá si los programadores de C++ tendrán Contracts en este estándar.

Qué pasó en la votación de C++26

La votación era sobre el Draft International Standard, la última votación completa antes de que ISO publique un estándar. Vota el organismo de normalización de cada país. The Register informó de 13 votos a favor, 9 en contra y 12 abstenciones. ISO no permite más de un 25 % de votos negativos.

Otras fuentes dan un recuento algo distinto. Una entrada de blog de Mond y un análisis de HFT University se basan en cifras publicadas por Robert Seacord, miembro del comité. Según ellas, 12 de los 20 miembros con voto aprobaron, por debajo de los 14 necesarios para los dos tercios. También dicen que 9 de 22 organismos votaron no, cuando se permiten como máximo 5. HFT University señala que el resultado oficial aún no es público. La publicación de Seacord lo dijo sin rodeos: "La votación de C++26 ha terminado. Por desgracia, fue desaprobada."

HFT University enumera los países que votaron no:

Voto	Países
No	Dinamarca, Finlandia, Irán, Italia, Japón, Luxemburgo, Rumanía, España, Suecia
Abstención con comentarios	Francia, Irlanda
Abstención	Polonia, Estados Unidos

Por qué los organismos nacionales votaron contra los Contracts

Los Contracts permiten escribir comprobaciones en la declaración de una función. Una precondición, escrita pre, dice qué debe cumplirse cuando se llama a la función. Una postcondición, escrita post, dice qué debe cumplirse cuando la función devuelve. Una sentencia contract_assert comprueba algo en mitad del código.

Bjarne Stroustrup, creador de C++, encabeza la oposición. "Los contracts de P2900 y sus extensiones pretenden cambiar la naturaleza de C++ y son una amenaza existencial para C++", dijo, según The Register. Andreas Fertig, miembro del comité, defendió el diseño: "Se ha trabajado en el tema durante años y ha recibido un voto mayoritario varias veces en su forma actual."

El análisis de Mond afirma que organismos de al menos siete países pidieron cambios que fueron rechazados. Algunos querían quitar los Contracts. Otros querían comprobaciones que no se pudieran desactivar. Al menos cuatro pidieron que la biblioteca estándar reforzada, que añade controles de seguridad al código de la biblioteca, no dependiera de los Contracts. El comité mantuvo ese vínculo.

Qué puede decidir WG21 en Búzios

The Register enumera tres opciones. WG21 puede eliminar los Contracts para que el resto de C++26 salga. Puede trasladar los Contracts a una Technical Specification aparte, un documento complementario fuera del estándar. O puede hacer una revisión menor y volver a votar.

Según Mond, dos documentos defienden cada postura. P4433R0, "Do not remove Contracts from C++26", advierte que quitarlos también obligaría a reescribir el texto sobre el refuerzo de la biblioteca. D4420, "Do Remove Contracts From C++26", de Vinnie Falco, defiende lo contrario. Si el estándar se retrasa, su nombre formal podría pasar a ser ISO/IEC 14882:2027, según The Register.

Probado: los Contracts de C++26 en GCC 16

La página de estado de GCC indica que los Contracts están disponibles desde GCC 16. La página de estado de Clang dice "No". En una prueba de Tech AI Wire en macOS 26 con GCC 16.2.0 dentro de un contenedor Docker Linux ARM64, un pequeño programa llamó a safe_div(10, 0) con esta comprobación:

int safe_div(const int a, const int b)
    pre(b != 0)
    post(r: r * b <= a)
{
    return a / b;
}

Cada compilación usó g++ -std=c++26 -fcontracts -O2 más un modo de -fcontract-evaluation-semantic=:

Modo	Qué pasó con safe_div(10, 0)	Código de salida
enforce (por defecto)	Mostró la violación y luego abortó	134
observe	Mostró la violación, siguió ejecutándose y mostró 0	0
quick_enforce	Abortó sin mensaje del contrato	134
ignore	Ninguna comprobación; mostró 0	0

Las compilaciones con ignore y observe mostraron 0 para 10 dividido entre 0, una respuesta sin sentido. El informe de violación indica el archivo, la línea y la condición: contract violation in function int safe_div(int, int) at contracts.cpp:4: b != 0.

Conviene conocer dos errores de compilación. El primer intento usó int a, int b sin más, y GCC lo rechazó: "a value parameter used in a postcondition must be const" (un parámetro por valor usado en una postcondición debe ser const). Una compilación con -std=c++26 pero sin -fcontracts compiló. Después falló al enlazar, con una referencia no definida a handle_contract_violation.

La prueba también contó las instrucciones máquina de la función compilada, solo con la precondición. Un if (b == 0) std::abort(); escrito a mano ocupó 6 instrucciones. quick_enforce ocupó 11, y enforce, 15. Al añadir -fno-contracts-conservative-ipa, bajaron a 6 y 9. Según la documentación de GCC, esa opción controla si el compilador puede optimizar a través del cuerpo de las funciones inline. HFT University observó el mismo patrón en procesadores x86.

Qué significa esto para los desarrolladores

No planifique todavía una base de código en torno a los Contracts estándar. La función puede eliminarse, retrasarse o cambiar en Búzios, y el informe de WG21 tras el 21 de noviembre dirá cuál de esas opciones gana. El código escrito hoy para la opción -fcontracts de GCC podría necesitar cambios.

Si prueba GCC 16 de todos modos, elija el modo a propósito. ignore y observe dejan que el programa siga tras un fallo. Por eso sirven para registrar errores, no para la seguridad. Declare los parámetros como const cuando una postcondición los lea. Compare quick_enforce con un simple if en sus propias rutas críticas antes de fiarse de su coste. Si depende del refuerzo de la biblioteca, vigile si sigue ligado a los Contracts después de la reunión.