Die Abstimmung, die C++26 abrupt stoppte
Der Weg von C++26 zur Standardisierung stieß am 24. Oktober 2026 auf ein beispielloses Hindernis. Der Entwurf scheiterte bei der ISO Draft International Standard (DIS)-Abstimmung, was das erste Mal ist, dass ein C++-Standard in diesem kritischen Stadium abgelehnt wurde. Diese Alles-oder-Nichts-Abstimmung erforderte von den Mitgliedsgremien die Zustimmung zum vollständigen Entwurf, nicht zu einzelnen Features.
Die Ergebnisse der Abstimmung waren eindeutig: Unter den teilnehmenden Mitgliedern stimmten nur 60 % (12 von 20) mit Ja, was unter der erforderlichen Zweidrittelmehrheit lag. Erschwerend kam hinzu, dass 9 von 22 Mitgliedsgremien mit „Nein“ stimmten, was die für eine Ablehnung zulässige Obergrenze von 25 % überschritt und einen alarmierenden Wert von 41 % erreichte. Dies war keine Absage an C++ oder eine pauschale Ablehnung jedes C++26-Features; es war ein entschiedenes Nein zum gesamten Paket, ausgelöst durch tiefgreifende Meinungsverschiedenheiten über einen einzigen umstrittenen Vorschlag.
Dieses Ergebnis bestätigt, dass nationale Gremien keine bloßen Abnick-Instanzen sind. Die Ablehnung bedeutet, dass der C++26-Standard in seiner jetzigen Form nicht weiterverfolgt wird. Die Community steht nun vor der komplexen Aufgabe, den Entwurf neu zu bewerten und zu überarbeiten, was die Veröffentlichung erheblich verzögern könnte.
Contracts wurden zum entscheidenden Streitpunkt
Contracts, die vorgeschlagenen Laufzeitprüfungen für C++26, wurden zum unbestrittenen Streitpunkt. Dieses Feature, das in P2900 detailliert beschrieben wird, zielte darauf ab, integrierte Preconditions, Postconditions und Assertions direkt in die Sprache einzuführen, wodurch Entwickler erwartete Programmzustände und Verhaltensweisen spezifizieren können.
Dies war keine kleine Ergänzung; allein die Contracts erweiterten den Standardentwurf um etwa 56 Seiten. Der Vorschlag spezifizierte vier implementierungsdefinierte Bewertungsmodi: ignore, observe, enforce und quick-enforce. Diese Flexibilität, die eigentlich an verschiedene Einsatzszenarien angepasst werden sollte, schürte stattdessen erheblichen Widerstand.
Kritiker, darunter C++-Schöpfer Bjarne Stroustrup, betrachteten Contracts als ein großes, unvollständiges und gefährliches Design. Sie argumentierten, dass es unnötige Komplexität, neue Wege für undefined behavior und einen grundlegenden Designfehler einführte: Laufzeitprüfungen, die in Produktions-Builds deaktiviert werden könnten (und wahrscheinlich würden). Dies, so argumentierten sie, untergrabe das Kernprinzip von C++ des Zero-Overhead und biete eine Lösung aus den 1980er Jahren für ein Problem, das besser durch moderne statische Analyse gelöst werden sollte.
Warum der Schöpfer von C++ sich dem Widerstand anschloss
Bjarne Stroustrup, der Schöpfer von C++, lehnte Contracts nicht nur ab; er half dabei, den Widerstand dagegen anzuführen. Im August veröffentlichten Stroustrup und vier Koautoren – J. Daniel Garcia, Vinnie Falco, John Spicer und Ville Voutilainen – P4334R0, „P2900 Contracts' Fundamental Flaws.“ Dieses Papier bezeichnete den Vorschlag als eine „existenzielle Bedrohung für C++“ und tat den Ansatz als „einen Ansatz aus den 1980er Jahren ab, der etwa 50 Jahre Fortschritt ignoriert.“
Die grundlegende Design-Kluft ist deutlich. Kritiker, einschließlich Stroustrup, plädieren für eine kohärente statische Analyse und robuste Sicherheitsgarantien. Sie argumentieren, dass reine Laufzeitprüfungen das Zero-Overhead-Prinzip von C++ verletzen, da sie aus Produktions-Builds entfernt werden. Sie machten zudem geltend, dass der Vorschlag neue Risiken für undefiniertes Verhalten und unbewiesene Vererbungsmodelle einführe.
Befürworter hingegen sehen Laufzeit-Contracts als ein praktisches, sofort nützliches Werkzeug zum Ausdrücken und Überprüfen von Programmannahmen – ein notwendiges Feature für die moderne Entwicklung. Weitere Informationen zum Vorschlag finden Sie unter P2900: Contracts for C++.
Das Gegenargument zu Stroustrups Sorge um den „Zero-Overhead“ ist ebenso überzeugend: Ein funktionierender Standardisierungsprozess sollte einen Vorschlag so tiefgreifend prüfen, anstatt einen Kompromiss des Komitees einfach durchzuwinken. Die Ablehnung von C++26 beweist, dass die nationalen Gremien aufmerksam sind und sicherstellen, dass neue Funktionen die höchsten Anforderungen erfüllen, auch wenn dies den Standard verzögert. Hier geht es nicht nur um Contracts; es geht um die Integrität des gesamten Standardisierungsprozesses.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Der Kollateralschaden – und die nächste Entscheidung
Die Alles-oder-nichts-Natur der C++26-Abstimmung bedeutet, dass Contracts nicht alleine gescheitert sind; sie haben den gesamten Standard mit sich gerissen. Mit Spannung erwartete Funktionen wie static reflection und std::execution befinden sich nun in der Schwebe. Dieser Kollateralschaden ist eine bittere Pille für eine Community, die auf Fortschritt hofft.
Diese Pattsituation entsteht zu einer Zeit, in der C++ zunehmend unter Druck steht, die Sicherheit und Zuverlässigkeit von Software zu verbessern. Konkurrierende Sprachen wie Rust und Swift bieten Garantien für Speichersicherheit und robuste Concurrency-Modelle, was das C++ Standards Committee unter Zugzwang setzt, sich weiterzuentwickeln. Die Industrie verlangt mehr als nur Performance; sie verlangt nachweisbare Korrektheit.
Nun muss das Komitee einen schwierigen Kurs einschlagen. Zu den Optionen gehören die Überprüfung der nationalen Kommentare und die Adressierung der Bedenken oder, drastischer, die vollständige Entfernung von Contracts, um den Zeitplan zu retten. Ein engerer Kompromiss könnte entstehen, aber der endgültige Weg und dessen Zeitplan bleiben höchst ungewiss. Diese Abstimmung beweist, dass ein einziges Feature tatsächlich alles aufhalten kann.
Häufig gestellte Fragen
Warum ist der C++26-Entwurf bei der ISO-Abstimmung gescheitert?
Der Entwurf erreichte nicht die erforderliche Zustimmungsschwelle und überschritt den zulässigen Anteil an negativen Stimmen. Uneinigkeit über den Contracts-Vorschlag wurde weithin als die zentrale Ursache angesehen.
Was sind Contracts in C++?
Contracts sind vorgeschlagene Sprachfunktionen zur Definition von Vorbedingungen, Nachbedingungen und Zusicherungen, die zur Laufzeit überprüft werden können.
Hat die Abstimmung alle Funktionen von C++26 abgelehnt?
Die Abstimmung betraf den vollständigen Entwurf des Standards, daher ist der Entwurf als Ganzes gescheitert. Die in der Quelle beschriebenen Einwände konzentrierten sich hauptsächlich auf Contracts, nicht auf jede einzelne C++26-Funktion.
Was passiert mit C++26 nach der gescheiterten Abstimmung?
Das Komitee muss die Kommentare der nationalen Gremien prüfen und entscheiden, ob Contracts entfernt, der Vorschlag überarbeitet oder ein anderer Weg eingeschlagen werden soll. Der Zeitplan für die Veröffentlichung ist ungewiss.