La votación ISO del borrador de C++26 no alcanzó el umbral requerido, con Contracts como principal foco de desacuerdo. El comité deberá decidir si retira la función, la separa del estándar o revisa la propuesta para intentar salvar el calendario.
***

• El borrador obtuvo 13 votos a favor, 9 en contra y 12 abstenciones, pero superó el límite permitido de votos negativos.
• Bjarne Stroustrup cuestiona la complejidad y el estado de Contracts; otros miembros sostienen que la propuesta ya recibió respaldo mayoritario.
• WG21 se reunirá en Búzios, Brasil, del 16 al 21 de noviembre para analizar alternativas que podrían preservar el lanzamiento de C++26 o llevarlo al próximo año.

C++26 enfrenta un último obstáculo por la disputa sobre Contracts

La próxima versión de C++ quedó en una situación incierta después de que el borrador C++26 no superara una votación de la Organización Internacional de Normalización (ISO). La principal controversia gira en torno a Contracts, una función que permitiría incorporar comprobaciones al código y que enfrenta a quienes la consideran útil para detectar errores con quienes advierten que su diseño añade complejidad y puede comprometer el calendario del estándar.

Una votación que frenó el borrador

En octubre, el Borrador de Estándar Internacional de C++26, conocido como DIS, recibió 13 votos favorables, 9 contrarios y 12 abstenciones. El resultado no cumplió la regla de la ISO, que exige que los votos negativos no superen el 25% para avanzar en esta etapa, por lo que el documento no obtuvo la aprobación necesaria.

La instancia del DIS es la penúltima fase del proceso de aprobación de la ISO, en la que los organismos nacionales de normalización revisan y ratifican formalmente los detalles técnicos. Que el texto haya fallado en este punto resulta inusual para C++, y abre una discusión que ya no se limita a la calidad de una función: también pone presión sobre el calendario de publicación previsto para 2026.

Contracts fue el principal motivo de desacuerdo entre quienes votaron en contra, según informó The Register. La propuesta P2900 permitiría que los programadores incluyeran precondiciones, postcondiciones y aserciones para comprobar si ciertas condiciones se cumplen durante la ejecución o en el uso del código, con la intención de hacer visibles algunos errores antes de que deriven en comportamientos indefinidos.

La discusión no enfrenta simplemente a partidarios de la seguridad con defensores de la velocidad. El desacuerdo abarca el alcance apropiado de la función, la forma de implementarla y el momento en que debería incorporarse a un estándar que ya llegó a una fase avanzada; por eso, incluso quienes valoran las comprobaciones pueden discrepar sobre si P2900 está lista para formar parte de C++26.

Qué está en juego con Contracts

El concepto de Design by Contract, o diseño por contrato, propone expresar condiciones que deben cumplirse antes y después de ejecutar una operación, además de verificaciones asociadas al funcionamiento del programa. Lenguajes como Ada y Eiffel cuentan desde hace tiempo con mecanismos de este tipo, mientras que en C++ los desarrolladores llevan al menos una década proponiendo incorporar Contracts.

La función ya había sido retirada de C++20 en medio de preocupaciones sobre valores predeterminados potencialmente peligrosos. La versión que llegó a C++26, P2900, reabrió el debate: sus defensores ven una vía para señalar fallos que de otro modo podrían pasar inadvertidos, pero sus críticos sostienen que la solución actual no ofrece una implementación suficientemente limpia.

Bjarne Stroustrup, creador de C++, encabezó las críticas a la propuesta junto con otros colegas en un artículo publicado en agosto. Allí afirmaron que Contracts y sus extensiones podrían cambiar la naturaleza del lenguaje, aumentar su complejidad y generar una expansión innecesaria; también cuestionaron que la implementación estuviera desordenada, desactualizada y poco probada, y plantearon que la función podría resolverse de forma más eficaz mediante una biblioteca.

La objeción de Stroustrup incluye una tensión técnica central para C++: agregar controles puede ayudar a detectar errores, pero también suscita preguntas sobre el rendimiento y sobre uno de los atributos que sus usuarios valoran, su velocidad. El artículo de la fuente relaciona ese debate con las críticas a la facilidad con que se pueden introducir vulnerabilidades en C++, un problema que ha llevado a algunos proyectos a adoptar Rust, aunque no plantea que Contracts por sí solo resuelva esos riesgos.

Confianza, calendario y alternativas

Andreas Fertig, miembro del comité de estandarización de C++, considera que las objeciones ya fueron discutidas y que frenar la propuesta en esta etapa perjudica al lenguaje. En una entrada de blog sostuvo que el tema se trabajó durante años y que su forma actual recibió varias veces el respaldo mayoritario, por lo que la derrota en la votación habría sacudido un proceso basado principalmente en la confianza y la colaboración respetuosa.

Fertig también acusó a Stroustrup y a sus aliados de no aceptar el resultado de las deliberaciones, al señalar que cada estándar reúne compromisos y que las partes pierden y ganan en distintos momentos. En su opinión, la pregunta inmediata es si el grupo podrá reconstruir la confianza; esa crítica expresa una disputa interna sobre el proceso, no una resolución formal del comité.

Harry Bott, director ejecutivo de C++ Alliance, que mantiene el front end de código abierto EDG, ofreció una lectura distinta. En declaraciones por correo electrónico a The Register, dijo que la devolución del borrador no representa un fracaso, sino que muestra que el proceso está funcionando como se diseñó, aunque también consideró que el episodio puede servir para mejorar y reforzar la confianza de los desarrolladores en la evolución de C++.

El grupo de trabajo ISO C++, WG21, se reunirá en Búzios, Brasil, del 16 al 21 de noviembre, según la agenda de la reunión. Allí discutirá cómo responder al rechazo. Entre las opciones descritas por Thibault Ricord-Marchal, consultor de ingeniería de software de la firma parisina Margo, están retirar Contracts para permitir que avance el resto de C++26, trasladar la función a una especificación técnica separada o hacer una revisión menor y someter el texto a otra votación.

El desenlace depende del grupo de trabajo

Excluir Contracts no sería un cambio sencillo, porque parte del trabajo de endurecimiento de bibliotecas ya se realizó apoyándose en esa función y habría que deshacerlo. La alternativa de una especificación técnica independiente permitiría continuar perfeccionando la tecnología fuera del estándar principal, mientras que una revisión acotada buscaría modificar la propuesta y volver a consultar a los organismos que participaron en la votación.

Si el proceso no termina a tiempo, C++ podría perder la fecha de lanzamiento prevista para 2026. La siguiente versión podría recibir informalmente el nombre de C++27, aunque la denominación oficial para una publicación el próximo año sería ISO/IEC 14882:2027; la diferencia importa porque el nombre comercial o habitual del ciclo no reemplaza la identificación formal del estándar.

El resultado de la reunión de WG21 deberá equilibrar dos objetivos que no necesariamente se excluyen, pero que los participantes priorizan de maneras distintas: conservar una función que sus partidarios consideran valiosa y evitar que una característica insuficientemente resuelta complique el lenguaje. Por ahora, la votación no determina por sí sola cuál de las salidas prevalecerá, y deja tanto la incorporación de Contracts como el calendario de C++26 sujetos a la decisión del grupo.

El debate también muestra por qué una votación negativa puede ser a la vez un revés y una oportunidad de revisión dentro de un proceso de estandarización. Para los usuarios de C++, la decisión que tome WG21 definirá si las comprobaciones llegan junto con la nueva versión, continúan su desarrollo por separado o quedan fuera de esta entrega.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín