C++26 a atteint un mur. Une fonctionnalité est à blâmer

Le parcours de C++26 vers la normalisation a rencontré un obstacle sans précédent le 24 octobre 2026. Le projet a échoué lors du vote ISO Draft International Standard (DIS), marquant la première fois qu'une norme C++ est rejetée à ce stade critique. Ce vote « tout ou rien » exigeait que les organismes membres approuvent le projet complet, et non des fonctionnalités individuelles.

Les résultats du vote ont été frappants : parmi les membres participants, seuls 60 % (12 sur 20) ont voté oui, ce qui est inférieur à la majorité des deux tiers requise. De plus, 9 des 22 organismes membres ont voté « Non », dépassant le plafond de 25 % autorisé pour un rejet, atteignant un taux alarmant de 41 %. Il ne s'agissait pas d'une annulation du C++ ou d'un rejet global de chaque fonctionnalité C++26 ; c'était un refus catégorique de l'ensemble du paquet, motivé par des désaccords profonds sur une seule proposition controversée.

Ce résultat confirme que les organismes nationaux ne sont pas de simples chambres d'enregistrement. Le rejet signifie que la norme C++26, telle qu'elle a été rédigée, ne pourra pas avancer. La communauté fait maintenant face à la tâche complexe de réévaluer et de réviser le projet, ce qui pourrait retarder considérablement la sortie.

Les Contracts, les vérifications à l'exécution proposées pour C++26, sont devenus le point de rupture incontesté. Cette fonctionnalité, détaillée dans P2900, visait à introduire des preconditions, postconditions, et assertions intégrées directement dans le langage, permettant aux développeurs de spécifier les états et comportements attendus du programme.

Ce n'était pas un ajout mineur ; les Contracts à eux seuls ont alourdi le projet de norme d'environ 56 pages. La proposition spécifiait quatre modes d'évaluation définis par l'implémentation : ignore, observe, enforce, et quick-enforce. Cette flexibilité, destinée à s'adapter à divers scénarios de déploiement, a plutôt alimenté une opposition significative.

Les critiques, dont le créateur du C++ Bjarne Stroustrup, considéraient les Contracts comme une conception vaste, incomplète et périlleuse. Ils ont fait valoir qu'ils introduisaient une complexité inutile, de nouvelles voies vers un undefined behavior, et un défaut de conception fondamental : des vérifications à l'exécution qui pourraient être (et seraient probablement) désactivées dans les builds de production. Cela, soutenaient-ils, sapait le principe fondamental du C++ de « zero-overhead » et offrait une solution des années 1980 à un problème mieux résolu par l'analyse statique moderne.

Bjarne Stroustrup, le créateur du C++, n'a pas seulement désapprouvé les Contracts ; il a aidé à mener la charge contre eux. En août, Stroustrup et quatre co-auteurs — J. Daniel Garcia, Vinnie Falco, John Spicer et Ville Voutilainen — ont publié P4334R0, “P2900 Contracts' Fundamental Flaws.” Ce document qualifiait la proposition de « menace existentielle pour le C++ » et rejetait son approche comme une « approche des années 1980 qui ignore environ 50 ans de progrès ».

Le fossé conceptuel est net. Les critiques, y compris Stroustrup, préconisent une analyse statique cohérente et des garanties de sécurité robustes, arguant que les vérifications uniquement à l'exécution violent le principe de « zero-overhead » du C++ en étant supprimées des builds de production. Ils ont également soutenu que la proposition introduisait de nouveaux risques d'undefined behavior et des modèles d'héritage non prouvés.

Les partisans, en revanche, considèrent les Contracts à l'exécution comme un outil pratique et immédiatement utile pour exprimer et vérifier les hypothèses du programme, une fonctionnalité nécessaire pour le développement moderne. Pour en savoir plus sur la proposition, consultez P2900: Contracts for C++.

Le contre-argument à la préoccupation de Stroustrup concernant le « zero-overhead » est tout aussi convaincant : un processus de normalisation fonctionnel doit examiner une proposition aussi profondément, plutôt que de valider aveuglément un compromis de comité. Le rejet de C++26 prouve que les organismes nationaux sont attentifs, garantissant que les nouvelles fonctionnalités atteignent le plus haut niveau d'exigence, même si cela retarde la norme. Il ne s'agit pas seulement de Contracts ; il s'agit de l'intégrité de l'ensemble du processus de normalisation.

La nature « tout ou rien » du vote C++26 signifie que les Contracts n'ont pas échoué seuls ; ils ont entraîné toute la norme avec eux. Des fonctionnalités très attendues, comme la static reflection et std::execution, languissent désormais dans l'incertitude. Ces dommages collatéraux sont une pilule amère pour une communauté avide de progrès.

Cette impasse survient alors que le C++ fait face à une surveillance accrue pour améliorer la sécurité et la fiabilité des logiciels. Des langages concurrents comme Rust et Swift offrent des garanties de sécurité mémoire et des modèles de concurrence robustes, mettant la pression sur le comité de normalisation C++ pour qu'il évolue. L'industrie exige plus que de simples performances ; elle exige une exactitude prouvable.

Désormais, le comité doit tracer une voie difficile. Les options incluent l'examen des commentaires nationaux et la résolution des préoccupations, ou, plus radicalement, la suppression totale des Contracts pour sauver le calendrier. Un compromis plus restreint pourrait émerger, mais la voie finale et son calendrier restent profondément incertains. Ce vote prouve qu'une seule fonctionnalité peut effectivement tout bloquer.

Pourquoi le projet C++26 a-t-il échoué à son vote ISO ?

Le projet n'a pas atteint le seuil d'approbation requis et a dépassé la part autorisée de votes négatifs. Le désaccord sur la proposition des Contracts a été largement considéré comme la cause principale.

Que sont les Contracts en C++ ?

Les Contracts sont des fonctionnalités de langage proposées pour exprimer des préconditions, des postconditions et des assertions qui peuvent être vérifiées à l'exécution.

Le vote a-t-il rejeté toutes les fonctionnalités de C++26 ?

Le vote couvrait l'ensemble du projet de norme, donc le projet a échoué dans sa globalité. Les objections décrites dans la source se concentraient principalement sur les Contracts, et non sur chaque fonctionnalité de C++26.

Qu'advient-il de C++26 après l'échec du vote ?

Le comité doit examiner les commentaires des organismes nationaux et décider s'il faut supprimer les Contracts, réviser la proposition ou suivre une autre voie. Le calendrier de publication est incertain.