Le projet C++26 a échoué au vote de l'ISO en raison de désaccords techniques profonds entre les pays concernant l'intégration des « contrats ».

C'est une première dans l'histoire du langage

La proposition de la norme C++26 a récemment été rejetée lors du vote des organismes nationaux sur le projet de norme internationale (DIS). La raison : des désaccords profonds concernant l'intégration des contrats dans le langage. Bien que de nombreux pays soutiennent l'idée d'ajouter des préconditions et postconditions vérifiables par le compilateur, les débats persistent sur la manière de gérer leur exécution et leurs sémantiques. Il s’agit du premier échec de ce type dans l’histoire de C++. Ce rejet met en suspens d'autres fonctionnalités très attendues, telles que la réflexion à la compilation et le modèle de programmation asynchrone std::execution.

C++26 est le nom informel donné à la version de la norme 14882 de l'Organisation internationale de normalisation (ISO) et de la Commission électrotechnique internationale (CEI) relative au langage de programmation C++ qui succède à la version C++23. C++26 a été officiellement finalisé le 28 mars 2026 par le comité international chargé de la normalisation (WG21) du langage. Le comité a aussi annoncé avoir adopté le calendrier de C++29.

Le 23 octobre 2026 avait lieu le vote des organismes nationaux sur le projet de norme internationale (DIS), l’étape précédant la publication de la norme. Lors de ce vote, il s’est produit quelque chose qui ne s’était jamais produit auparavant : le projet C++26 a été rejeté. Robert Seacord, président du comité C à l’ISO, l’a annoncé laconiquement sur sa page LinkedIn le 24 octobre : « le vote sur C++26 est terminé. Malheureusement, il a été rejeté ».

Pour être validé, un projet de norme doit recueillir au moins deux tiers de votes favorables des membres votants et ne pas dépasser 25 % d'oppositions. Le résultat du vote n'a satisfait aucun de ces deux critères, ne réunissant que 60 % d'avis favorables (12 voix sur 20) et comptabilisant 41 % de votes contre (9 voix sur 22). Neuf pays ont voté contre le projet : Danemark, Finlande, Iran, Italie, Japon, Luxembourg, Roumanie, Espagne et Suède.

La Pologne et les États-Unis se sont abstenus sans commentaires. La France et l’Irlande se sont également abstenues, mais ont envoyé des commentaires. Les commentaires ne sont pas encore publics. Selon les règles de l’ISO, le rapport complet sera publié sous 12 semaines, soit au plus tard à la mi-janvier 2027.

Cet échec a déclenché un débat. Mateusz Pusz, auteur de la bibliothèque mp-units et membre du comité national polonais, explique cela en détail dans « Le résultat du vote DIS sur le C++26 », le sixième article d’une série consacrée au différend qui se cache derrière cette décision. Daveed Vandevoorde, membre du groupe de direction du comité C++, a écrit qu’aucun projet de C++ antérieur n’avait jamais reçu ne serait-ce qu’un seul vote contre.

Les contrats : le cœur des désaccords techniques sur C++ 26

Bien que les commentaires ne soient pas encore connus, Mateusz Pusz se dit convaincu que les neuf votes contre portent tous sur les contrats, et il a de bonnes raisons de le penser : toutes les objections consignées avant le vote allaient dans ce sens. Les deux objections soulevées lors de la séance plénière qui a soumis C++26 au vote portaient sur les contrats ; plusieurs pays avaient déjà demandé leur suppression lors de l’étape précédente.


Les contrats (Contracts) introduisent dans le langage des mécanismes formels pour définir des préconditions, des postconditions et des assertions directement dans les déclarations de fonctions. Cette fonctionnalité remplace avantageusement la macro assert du langage C en offrant une intégration native qui renforce la sécurité fonctionnelle et la clarté des interfaces logicielles. Cette nouvelle fonctionnalité ne bénéficie pas du soutien de tous.

L'intégration des contrats a fait l'objet de débats techniques prolongés au sein du comité ISO en raison de diverses inquiétudes d'experts. Elles étaient toutefois minoritaires. Les membres ont finalement voté pour leur maintien dans C++26, estimant que l'apport pour la fiabilité des programmes l'emportait sur les divergences de conception. Lors du vote final pour livrer le standard, le résultat a été de 114 voix pour, 12 contre et 3 abstentions.

Il y a eu un rebondissement lors du vote des comités nationaux sur le projet de normalisation. La principale raison du rejet exprimée par les comités nationaux réside dans l'intégration des contrats, jugée prématurée par les opposants. En plus des signes susmentionnés, un document, le P4238R1, demandait explicitement aux comités nationaux de voter contre en raison de la conception des contrats et de la manière dont celle-ci avait été approuvée.

Cependant, des désaccords profonds subsistent sur les détails de mise en œuvre, notamment autour des quatre sémantiques proposées (ignore, observe, enforce et quick-enforce), ainsi que sur « la possibilité pour les compilateurs de l'industrie de retirer ou non ces contrôles sans garantie stricte ».

Le code ne décide donc pas si chaque vérification s’exécute ni ce qui se passe en cas d’échec. Une grande partie du débat porte sur ce point : un contrat est-il une vérification que la compilation peut ignorer ou une garantie sur laquelle le programme peut s’appuyer ? Un débat porte également sur ce qui peut mal tourner au sein même du prédicat, et sur la question de savoir s’il existait suffisamment d’expérience en production avant de le normaliser.

Des fonctionnalités majeures bloquées et des options limitées

Les contrats ont aussi été retirés de C++20 : ce n’est pas une première. L'échec du vote DIS n'impacte pas seulement la fonctionnalité des contrats, mais bloque simultanément l'ensemble des évolutions prévues pour C++26. Des avancées très attendues (comme la réflexion à la compilation, le modèle de programmation asynchrone std::execution et le durcissement de la bibliothèque standard) se trouvent gelées en raison du projet non approuvé.

La procédure ISO prévoit quatre issues possibles : soumettre une version révisée pour un nouveau vote DIS, faire revenir le projet à l'étape de projet de comité, publier les spécifications sous la forme d'un document technique séparé, ou abandonner le projet. La date finale de publication et la nomination du standard restent indéterminées. Selon Daveed Vandevoorde, le nom C++27 pourrait devenir plus exact si la sortie officielle est repoussée.

Ce ne serait pas inhabituel : la norme C++23 a été publiée si tardivement qu'elle porte officiellement la référence ISO/IEC 14882:2024. En attendant, la norme actuellement en vigueur reste la C++23. La prochaine réunion du comité C++ se tiendra à Búzios, au Brésil, du 16 au 21 novembre, et les avis sont partagés :

• supprimer les contrats afin que le reste puisse être publié dès que possible : pour J. Daniel García, l’un des auteurs du P4238R1, la solution à court terme est simple : « supprimer une fonctionnalité problématique et le reste de la norme pourra très probablement être approuvé » ;
• voter à nouveau sans modifier les contrats : c’est ce que propose la proposition P4433R0, signée par seize partisans des contrats, qui font également valoir que leur suppression ne serait pas rapide, car il s’agit d’un changement majeur qui obligerait à repenser le renforcement de la sécurité des bibliothèques ;
• transférer les contrats dans une spécification technique ou un document distinct, comme l’ont demandé certains pays.

Pour Andreas Fertig, membre du comité de normalisation, ce blocage ébranle le modèle de consensus et de confiance mutuelle qui prévalait jusqu'alors : « une catastrophe de grande ampleur et je compatis avec l'ensemble de la communauté C++ ». Tous attendent désormais la prochaine réunion au Brésil.

Cap sur C++29 : ajouter encore plus de sécurité mémoire

Le comité a adopté le calendrier de C++29 lors de la dernière réunion à Croydon. Le secrétaire du comité Herb Sutter a rapporté que ce nouveau cycle de trois ans se concentrera prioritairement sur le renforcement de la sécurité mémoire à travers le concept de profils et la réduction continue des comportements indéfinis. Les profils ont été proposés par le créateur du langage C++, Bjarne Stroustrup. Mais cette fonctionnalité fait l'objet de controverses.

« Le groupe de travail sur la sécurité et la sûreté a voté pour donner la priorité aux Profils plutôt qu'à Safe C++. Demandez aux responsables des Profils de vous tenir au courant. Safe C++ n'est pas poursuivi », a rapporté Sean Baxter, auteur du compilateur Circle C++. Safe C++ visait à doter le langage d'un modèle de sécurité inspiré de Rust, mais il a été rejeté, car il introduirait des contraintes jugées trop lourdes pour l’écosystème C++.

Cette transition vers un C++ plus sûr par défaut tout en respectant le principe de "zéro coût" marque le début d'une nouvelle ère pour le langage. Un rapport d'expérience présenté par Apple décrit comment le moteur de rendu de navigateur WebKit a durci plus de 4 millions de lignes de code en utilisant une approche par sous-ensemble du langage, fermant plusieurs classes de vulnérabilités et empêchant l'exploitabilité de nombreux bogues.

Source : billet de bogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'échec de l'adoption de la norme ISO C++26 ?
Que pensez-vous des contrats intégrés à cette version langage de programmation ?
En quoi rendent-ils le langage meilleur ? Comprenez-vous les oppositions à cette fonctionnalité ?

Voir aussi

C++26 est prêt : la nouvelle norme apporte des améliorations en matière de sécurité mémoire et serait la version « la plus aboutie » depuis C++11. Elle introduit les contrats et la bibliothèque std::execution

Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils », une alternative controversée proposée par le créateur du langage

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté veut répondre aux défis modernes de la sécurité des logiciels, dans un contexte où plusieurs recommandent de le remplacer par des alternatives