C++26 échoue au vote ISO à cause des Contracts, testé dans GCC 16

Le projet de C++26, la prochaine version de la norme du langage C++, a échoué à son vote ISO en octobre 2026. La dispute qui l'a fait tomber porte sur une seule fonctionnalité : les Contracts. Le comité C++, appelé WG21, se réunit du 16 au 21 novembre à Búzios, au Brésil. Il y décidera s'il supprime la fonctionnalité, la déplace ailleurs ou la soumet à un nouveau vote. Le résultat décidera si les programmeurs C++ auront ou non les Contracts dans cette norme.

Ce qui s'est passé lors du vote sur C++26

Le vote portait sur le Draft International Standard, le dernier vote complet avant que l'ISO ne publie une norme. L'organisme de normalisation de chaque pays vote. The Register a rapporté 13 voix pour, 9 contre et 12 abstentions. L'ISO n'autorise pas plus de 25 % de votes négatifs.

D'autres récits donnent un décompte un peu différent. Un billet de blog de Mond et une analyse de HFT University s'appuient tous deux sur des chiffres publiés par Robert Seacord, membre du comité. Selon eux, 12 des 20 membres votants ont approuvé, en dessous des 14 nécessaires pour les deux tiers. Ils indiquent aussi que 9 des 22 organismes ont voté non, alors que 5 au plus sont permis. HFT University note que le résultat officiel n'est pas encore public. Le message de Seacord était clair : « Le vote sur C++26 est terminé. Malheureusement, il a été désapprouvé. »

HFT University liste les pays qui ont voté non :

Vote	Pays
Non	Danemark, Finlande, Iran, Italie, Japon, Luxembourg, Roumanie, Espagne, Suède
Abstention avec commentaires	France, Irlande
Abstention	Pologne, États-Unis

Pourquoi des organismes nationaux ont voté contre les Contracts

Les Contracts permettent d'écrire des vérifications dans la déclaration d'une fonction. Une précondition, écrite pre, dit ce qui doit être vrai quand la fonction est appelée. Une postcondition, écrite post, dit ce qui doit être vrai quand elle retourne. Une instruction contract_assert vérifie quelque chose au milieu du code.

Bjarne Stroustrup, le créateur de C++, mène l'opposition. « Les contracts de P2900 et leurs extensions visent à changer la nature de C++ et sont une menace existentielle pour C++ », a-t-il déclaré, selon The Register. Andreas Fertig, membre du comité, a défendu la conception : « Le sujet a été travaillé pendant des années et a obtenu un vote majoritaire à plusieurs reprises sous sa forme actuelle. »

L'analyse de Mond indique que des organismes d'au moins sept pays ont demandé des changements qui ont été rejetés. Certains voulaient retirer les Contracts. D'autres voulaient des vérifications impossibles à désactiver. Au moins quatre ont demandé que la bibliothèque standard renforcée, qui ajoute des contrôles de sécurité au code de la bibliothèque, ne dépende pas des Contracts. Le comité a gardé ce lien.

Ce que WG21 peut décider à Búzios

The Register cite trois options. WG21 peut retirer les Contracts pour que le reste de C++26 sorte. Il peut déplacer les Contracts dans une Technical Specification séparée, un document annexe hors de la norme. Ou il peut faire une révision mineure et voter à nouveau.

Selon Mond, deux documents défendent chacun un camp. P4433R0, « Do not remove Contracts from C++26 », avertit qu'un retrait obligerait aussi à réécrire le texte sur le renforcement de la bibliothèque. D4420, « Do Remove Contracts From C++26 » de Vinnie Falco, défend l'inverse. Si la norme prend du retard, son nom officiel pourrait devenir ISO/IEC 14882:2027, selon The Register.

Testé : les Contracts de C++26 dans GCC 16

La page de statut de GCC indique les Contracts comme disponibles à partir de GCC 16. La page de statut de Clang indique « No ». Dans un test de Tech AI Wire sous macOS 26 avec GCC 16.2.0 dans un conteneur Docker Linux ARM64, un petit programme a appelé safe_div(10, 0) avec cette vérification :

int safe_div(const int a, const int b)
    pre(b != 0)
    post(r: r * b <= a)
{
    return a / b;
}

Chaque compilation utilisait g++ -std=c++26 -fcontracts -O2 plus un mode de -fcontract-evaluation-semantic= :

Mode	Ce qui s'est passé sur safe_div(10, 0)	Code de sortie
enforce (par défaut)	A affiché la violation, puis a interrompu le programme	134
observe	A affiché la violation, a continué, a affiché 0	0
quick_enforce	A interrompu le programme sans message de contrat	134
ignore	Aucune vérification ; a affiché 0	0

Les versions ignore et observe ont toutes deux affiché 0 pour 10 divisé par 0, une réponse sans aucun sens. Le rapport de violation donne le fichier, la ligne et la condition : contract violation in function int safe_div(int, int) at contracts.cpp:4: b != 0.

Deux erreurs de compilation sont bonnes à connaître. Le premier essai utilisait de simples int a, int b, et GCC a refusé : « a value parameter used in a postcondition must be const » (un paramètre par valeur utilisé dans une postcondition doit être const). Une compilation avec -std=c++26 mais sans -fcontracts a compilé. Elle a ensuite échoué à l'édition de liens, avec une référence indéfinie à handle_contract_violation.

Le test a aussi compté les instructions machine de la fonction compilée, avec la seule précondition. Un if (b == 0) std::abort(); écrit à la main prenait 6 instructions. quick_enforce en prenait 11, et enforce 15. Avec -fno-contracts-conservative-ipa en plus, ils sont descendus à 6 et 9. Selon la documentation de GCC, cette option contrôle si le compilateur peut optimiser à travers le corps des fonctions inline. HFT University a constaté la même tendance sur des processeurs x86.

Ce que cela signifie pour les développeurs

Ne bâtissez pas encore une base de code autour des Contracts standard. La fonctionnalité peut être supprimée, retardée ou modifiée à Búzios, et le rapport de WG21 après le 21 novembre dira laquelle de ces options l'emporte. Du code écrit aujourd'hui pour l'option -fcontracts de GCC pourrait devoir être modifié.

Si vous testez GCC 16 malgré tout, choisissez le mode exprès. ignore et observe laissent le programme continuer après un échec. Ils conviennent donc à la journalisation, pas à la sécurité. Déclarez les paramètres const quand une postcondition les lit. Comparez quick_enforce à un simple if dans vos propres chemins critiques avant de vous fier à son coût. Si vous comptez sur le renforcement de la bibliothèque, surveillez s'il reste lié aux Contracts après la réunion.