C++26 recalé à l'ISO, une première : les contrats ne passent pas

Un vote raté sur les deux tableaux

Le 23 octobre, les organismes nationaux membres de l’ISO votaient sur le projet de norme internationale (DIS) du C++26. Le lendemain, sur LinkedIn, Robert Seacord, qui dirige le comité du langage C à l’ISO, annonçait que le texte avait été désapprouvé et parlait d’un « jour triste pour la communauté C++ ». Ce 4 novembre, Next a expliqué les raisons de cet échec.

Pour être adopté, un projet doit remplir deux conditions : réunir les deux tiers des voix des membres participants et ne pas dépasser un quart de votes négatifs. Le C++26 a obtenu 12 voix sur 20, soit 60 %, alors qu’il en fallait 14. Côté refus, il a recueilli 9 votes contre sur 22, soit 41 %. Il échoue donc sur les deux critères, ce qui a au moins le mérite de la cohérence.

Selon Mateusz Pusz, membre du comité national polonais, neuf pays ont voté contre : le Danemark, la Finlande, l’Iran, l’Italie, le Japon, le Luxembourg, la Roumanie, l’Espagne et la Suède. La France et l’Irlande se sont abstenues en envoyant des commentaires techniques. La Pologne et les États-Unis se sont abstenus sans commentaire. Pour Robert Seacord, aucune norme de langage n’avait jamais échoué à ce stade. Daveed Vandevoorde, du groupe de direction du comité C++, va plus loin : jusqu’ici, aucun projet n’avait reçu un seul vote contre.

Les contrats, une idée consensuelle à la conception explosive

Un contrat inscrit dans la déclaration d’une fonction ce qu’elle exige de celui qui l’appelle (la précondition) et ce qu’elle garantit en retour (la postcondition). Une fonction racine carrée, par exemple, exige un nombre positif et promet un résultat positif. Bertrand Meyer a popularisé le principe dans les années 1980 avec le langage Eiffel, et Ada comme D l’intègrent aussi. Ses défenseurs y voient une documentation qui ne peut pas devenir obsolète en silence. Dans la plupart des dépôts, cela relève encore de la science-fiction.

Le comité C++ travaille sur le sujet de façon concertée depuis 2004. Une première version, prévue pour C++20, a été retirée en 2019. La version actuelle avait pourtant été approuvée par un sous-comité technique en février 2025, par 100 voix contre 14. Tout le monde veut des contrats ; c’est leur conception qui divise.

Ce que l’option de compilation décide à votre place

Dans C++26, ce n’est pas le code source qui décide si un contrat est vérifié. Le texte prévoit quatre comportements : ignorer la vérification, vérifier et signaler l’erreur sans s’arrêter, vérifier et arrêter le programme, ou arrêter le programme immédiatement sans traitement intermédiaire. Le choix revient à l’implémentation, autrement dit à une option de compilation.

Pour vous qui écrivez le code, la conséquence est concrète. La même précondition peut être appliquée strictement, simplement signalée ou ignorée, selon la manière dont le binaire est construit. Côté compilateur, un simple réglage peut ainsi changer le sens d’une ligne. Dans son billet, Mateusz Pusz résumait le dilemme : une assertion de contrat est-elle une vérification que la compilation peut supprimer, ou une garantie sur laquelle le programme peut compter ?

Deux camps qui ne compilent pas ensemble

Les opposants s’en prennent justement à cette possibilité de désactiver les vérifications. Selon eux, ce serait faire entrer dans la norme une pratique bien connue : tester avec des contrôles, puis les retirer en production. Ils veulent des vérifications toujours actives, dont Google estime le coût à 0,3 %. Ils jugent aussi le dispositif inachevé et citent le cas des contrats sur les fonctions virtuelles.

Pour l’heure, le texte soumis au vote le 23 octobre n’est donc pas une norme ISO.

Pour la première fois de son histoire, c’est la norme elle-même qui a échoué sur une précondition, et personne n’a pu désactiver la vérification à la compilation.