Herb Sutter: el veto de Stroustrup que frena C++26

Un 90% de consenso no fue suficiente

114 expertos a favor y 12 en contra. Ese fue el resultado de la votación de Croydon, en marzo de 2026, sobre incluir contracts —programación por contrato— en el estándar C++26. Meses después, ese mismo borrador no superó la votación formal del DIS. En P4454R0, un documento fechado el 31 de octubre de 2026, Herb Sutter, miembro del comité ISO de C++ (WG21), sostiene que el proceso no fue el factor decisivo: lo fue que Bjarne Stroustrup, el creador del lenguaje, se opusiera, y que los organismos nacionales decidieran darle más peso a él que al consenso del comité.

Para un founder, el caso es un espejo incómodo. Tu equipo técnico puede tener razón, haberla defendido durante dos años y aun así perder la votación, si la persona que encarna la autoridad del producto no está de acuerdo. Y el final habitual de ese choque, según el propio documento, es fork o salida.

¿Qué pasó exactamente con C++26?

El estándar C++ se decide en la ISO, dentro del grupo de trabajo WG21, que según el documento reúne a unos 600 expertos en su directorio. El paso final de cada versión es el DIS (Draft International Standard): un balotaje en el que los organismos nacionales de normalización —los propietarios formales del lenguaje— aprueban o rechazan el borrador.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

WG21 llegó a ese balotaje con contracts dentro de C++26. Y lo perdió. El documento no relitiga si contracts era buena idea: se concentra en qué hace el comité cuando el creador del lenguaje rechaza su consenso y los organismos nacionales, con la información que tienen, le dan la razón al creador.

¿Por qué el consenso del comité no bastó?

Sutter revisa una por una las explicaciones que circulan y las descarta como factor decisivo. Ni el relleno de la sala con votantes afines ni el conteo por empresa cambiaron el resultado: los presidentes de EWG (el grupo de evolución del lenguaje) contaron dos veces cada votación para deduplicar por compañía, incluyendo empleados y contratistas, y el resultado no se movió de forma material. Tampoco fue solo el proceso de los study groups, que el propio Sutter admite imperfecto. Contracts estuvo dos años en EWG y en plenario, y ahí sí hubo consenso.

Lo nuevo fue otra cosa. Stroustrup, que lleva 36 años señalando errores al comité sin romper el consenso, esta vez concluyó que el diseño de contracts es demasiado defectuoso para aceptarlo. Su diagnóstico, citado en el documento y desarrollado en su paper P4334R0, es que el diseño es fundamentalmente fallido: agrega inseguridades, deja instalaciones clave definidas por la implementación, restringe el manejo de violaciones, suma sobrecarga y tiene semántica determinada por los interruptores del compilador.

El detalle que convierte esto en una lección de gobernanza: según Sutter, solo cinco personas —alrededor del 1% de los 600 expertos— hicieron campaña activa ante los organismos nacionales, y más de la mitad de los organismos que votaron en contra nunca habían participado en WG21. Votaron después de recibir mensajes que citaban la oposición de Stroustrup. En la práctica, dice el autor, los organismos nacionales le dieron a su disenso un veto de facto.

Es la parte incómoda: el argumento que ganó no fue el mejor argumento técnico, fue el de mayor reputación.

¿Qué pasó en otras comunidades cuando el creador chocó con el comité?

El documento repasa casos conocidos y encuentra el mismo patrón:

C (1988). Dennis Ritchie exigió al comité ANSI X3J11 eliminar noalias. Se eliminó para C89. Ritchie llamó a su propia nota una jeremiad y admitió que la frase políticamente imposible del comité era, en parte, código para decir que Dennis no lo iba a tolerar.
Pascal. Niklaus Wirth se marchó a Modula-2 y Oberon; Extended Pascal se estandarizó sin él y tuvo poca adopción.
Perl. Larry Wall empujó Perl 6 y buena parte de la comunidad se quedó en Perl 5. El fork fue permanente: Perl 6 se renombró Raku en 2019.
JavaScript. El ambicioso ES4 de Brendan Eich no alcanzó consenso en ECMA TC39. Se abandonó, pero ES5 y ES2015 absorbieron muchas de sus ideas por partes.
Java. James Gosling empujó los closures completos; se postergaron años. Salió de Oracle en 2010, citando después problemas de cultura.
Rust. Graydon Hoare perdió muchas discusiones de diseño, dejó el proyecto y escribió más tarde The Rust I Wanted Had No Future.
Python. Guido van Rossum impuso las assignment expressions (PEP 572) contra una oposición fuerte, ganó la decisión y renunció como BDFL, la figura del dictador benevolente vitalicio; hoy gobierna un steering council y él volvió como un participante más.
Swift. Chris Lattner citó un ambiente tóxico en las reuniones del core team y se fue.

Tres patrones se repiten. Primero: la palanca del creador es la reputación, no el voto — Ritchie no tenía voto en X3J11 y Stroustrup no tiene un estatus especial en el procedimiento ISO; su influencia viene de la confianza del mundo. Segundo: la objeción funciona mejor cuando es estrecha, técnica y rara. Tercero: si ninguna de las dos partes cede, el resultado es fork o salida.

Las seis salidas que el documento pone sobre la mesa

Sutter no elige una, pero deja el mapa completo: A) no publicar C++26 y avanzar directo a C++29; B) sacar contracts del DIS, rebalotear y volver a comparar propuestas rivales sin un diseño incumbente; C) rebalotear con un anexo que documente el razonamiento del comité y hacer campaña ante los organismos nacionales; D) balotear el borrador posterior a Búzios como nuevo DIS; E) que los organismos que quieran C++26 lo publiquen como estándar nacional; F) la opción E más estudiar mover el trabajo a un organismo nacional abierto o a la Linux Foundation, donde todos los expertos serían iguales.

Stroustrup, según el documento, prefiere la B, idealmente con un nuevo borrador de DIS en seis semanas para que el trabajo técnico siga contando como completado en 2026.

¿Qué significa esto para tu startup?

La traducción es directa: en cualquier proyecto con un fundador visible, el consenso del equipo pierde frente a la reputación del fundador. No porque el equipo esté equivocado, sino porque quienes deciden desde fuera —inversores, clientes, board— pesan más la voz de quien tiene el historial.

Tres cosas concretas que puedes hacer esta semana:

Diseña el canal de disenso antes de que haga falta. El documento propone que el comité registre explícitamente las objeciones sostenidas y las discuta en plenario antes de avanzar. En tu empresa: define hoy qué pasa cuando el fundador o el CTO técnico no está de acuerdo con una decisión de roadmap, y a qué foro sube esa discusión. Si lo resuelves cuando el conflicto ya estalló, la conversación será sobre lealtades y no sobre el problema.
Acuerda evidencia medible, no opiniones. Sutter sugiere que las dos partes de contracts escriban de antemano qué resultados de implementación y despliegue confirmarían o desmentirían sus preocupaciones, y pide ser medible. Llévalo a tu equipo: define un umbral verificable (por ejemplo, que el costo de una función caiga por debajo de un nivel con datos de producción) antes de comprometer recursos. Los desacuerdos sobre predicciones se resuelven con experiencia; los desacuerdos sobre gusto, no, y tres años más no los arreglan.
Documenta el porqué, no solo el qué. Si vas a ir contra la opinión de tu fundador o de tu inversor de referencia, el acta con el razonamiento técnico es tu único activo cuando la decisión se juzgue desde fuera.

Conclusión

C++26 es un caso de estudio caro: un comité de 600 expertos con 90% de acuerdo no consiguió publicar un estándar porque su creador dijo que no. La lección no es que la autoridad técnica no importe, sino que la autoridad reputacional decide en la última milla. En un proyecto abierto eso se gestiona con proceso, transparencia y evidencia acordada de antemano. En una startup, con las mismas tres piezas: un foro claro para disentir, métricas definidas antes del conflicto y un registro escrito de por qué se decidió lo que se decidió.

Este análisis se basa en el documento P4454R0; no se localizaron coberturas periodísticas adicionales verificables sobre el caso.