From looking around, it seems this was due to controversy regarding contracts? It almost seems like a political split going on there, with some people blaming the standards bodies and others blaming WG21 but all with somewhat fuzzy reasons. I'm curious if anyone has some info on the disagreements who isn't actually deep enough in this to have taken a side already?
My understanding is that Bjarne has been going around trying to prevent contracts from going in. I think he's right on this one (even though I otherwise largely disagree with him wrt profiles), but it's very hard for me to tell whether blocking the standard with the national bodies is remotely worth it or proportional.
No clue what happens next! I assume the ideal would be that contracts get thrown out, then they redo the vote and the standard passes, and hopefully this happens relatively quickly? Worst case would be that there'll be no C++26?
It’s complicated and I don’t fully understand it. Apparently individual member bodies can ratify and publish it, so what happens if ANSI ratifies it but ISO doesn’t? There’s now a C++26 but it isn’t an ISO standard. Fun times. If there is no ratified ISO standard, the current draft remains the working draft, so the next ISO standard will be based on it. There’s no process for accepting the standard with contracts removed.
I am one of the people strongly objected to contracts and regard it as a disaster for the language, but I gave up engaging (and did not vote in my national body vote) because I lost faith in the process as something able to produce a good outcome. My engagement is now very narrowly focused on trying to make sure that we have sensible definitions of pointer behaviour.
It’s complicated and I don’t fully understand it. Apparently individual member bodies can ratify and publish it, so what happens if ANSI ratifies it but ISO doesn’t? There’s now a C++26 but it isn’t an ISO standard. Fun times. If there is no ratified ISO standard, the current draft remains the working draft, so the next ISO standard will be based on it. There’s no process for accepting the standard with contracts removed.
My current guess (based on nothing) is that the draft will be sent back to WG21, has a chance to be amended (either removing or affirming contracts), and will then get another vote by the national bodies. Do you think that's likely?
My engagement is now very narrowly focused on trying to make sure that we have sensible definitions of pointer behaviour.
Probably unrelated to this discussion, but I'd be interested to hear what you're working on here. Is this a pointer provenance thing? Is it about ensuring CHERI compatibility? I didn't know there's any "open discussions" on pointer behavior in C++, I figured most of this would be completely set in stone.
Probably unrelated to this discussion, but I'd be interested to hear what you're working on here. Is this a pointer provenance thing? Is it about ensuring CHERI compatibility? I didn't know there's any "open discussions" on pointer behavior in C++, I figured most of this would be completely set in stone.
The core model is fairly uncontentious but there are other things like the semantics of intprt_t. In C, it remains optional. C++ has made it mandatory but with implementation-defined semantics. I’m working (though haven’t updated the paper for a bit) on codifying the semantics to permit both what CHERI does and a slightly more lenient model.
In particular, there are some simple things people expect. If you cast a pointer to an intprt_t and add N, then cast back, the result should be the same as if you’d cast to char*. This is not guaranteed by C or C++ but it’s such an obvious ‘of course it works that way’ thing that an implementation that didn’t preserve that property would not work for most non-trivial codebases. And, since compilers have to be able to do the right thing for char*, all implementations can do that.
Other arithmetic also needs to be defined in similar terms. In the CHERI C/C++ work, we found that the most common use of intprt_t was to align pointers up and down. That use requires masking the low bits. Again, that should be defined because it’s currently 100% implementation-defined but people assume it works (we had to make it work with CHERI C/C++ because the other option was break everything).
Beyond that, I want some feature-test macros that define whether arithmetic that takes the address to another object is defined. It doesn’t work in CHERI, but it is expected to in some low-level systems code (e.g. CPU-local storage in the FreeBSD kernel), so there needs to be a way for software to say ‘I assume this works, static assert fail if it doesn’t on thei target’.
My understanding is that Bjarne has been going around trying to prevent contracts from going in. I think he's right on this one (even though I otherwise largely disagree with him wrt profiles), but it's very hard for me to tell whether blocking the standard with the national bodies is remotely worth it or proportional.
Oh wow, yes that seems quite severe. Looking more through some of these papers, I get some of the complaints for sure (mostly that relying on them for UB checks but then letting you turn them off is going to be a mess), but some of this wording seems like contracts are solely destructive. To be frank, the standards committees have been adding dysfunctional features for a long time, and sometimes they even later get fixed, so... I'm not sure if rounding up the international standards bodies here is a proportional action.
If Stroustrup is leading the fight against it, this does kinda seem more like a political fight, where some people who oppose it don't really want to be overridden on anything (and, perhaps, some in support wishing for the opposite).
There are multiple papers and afaik talks on "why contracts are bad" , I'd look them up for references. Afaik a lot of stuff about the one definition rule, and "how do you selectively enable or disable contracts" etc. I'd look them up for references if you want to dive deeper.
That said, afaik there was "strong consensus" to get contracts in by the standard bodies.
I have not fully kept up on the current technical statusof the draft but Bjarne being actively involved (and against contracts) is afaik confirmed.
I would be very interested to watch those talks on why contracts are bad. Do you remember a name, the speaker, the conference or anything else which could be used to find them?
Every complaint in P4334 had been brought to the committee, heard and considered, prior to voting to approve contracts in C++26. It is strange that the paper didn't acknowledge this, and the fact that you appear to believe that these complaints had not been considered is why ISO CoCs expect papers to contain relevant information like that.
It's very much a shame that a paper in this state was circulated in a way that continues to mislead readers into believing that the complaints had not already been heard and considered.
and the fact that you appear to believe that these complaints had not been considered
@refi64 never said this. They literally link to a paper which says "WG21 has carefully considered each individual concern, weighed the trade-offs involved, and ultimately decided, in each case, in
favour of the specification that is now in the C++26 DIS".
P4334 is useful for people like me who are out of the loop and want to understand where the disagreements lie with contracts. Clearly there's still no consensus, and plenty of people are very unhappy with contracts in their current state, and so it's nice to have some context on why that is. Just linking to a paper (alongside other papers showing the opposite side's stance!) doesn't imply that it hasn't been "heard and considered" by the committee.
Where are you getting this claim of no consensus then? Clearly you read this paper and came to the conclusion that there was no consensus, because this paper is written in a way that makes you think that.
To cite Herb Sutter's trip report[1] from croydon, first that "lack of consensus vote" to pull contracts into C++26:
In February 2025 when we took the plenary poll to adopt contracts in the C++26 working draft (“merge it to trunk”), the vote was:
100 in favor, 14 opposed, and 12 abstaining
And in 2026 the vote to approve C++ 26, with the inclusion of contracts
the vote was non-unanimous primarily because of the sustained concerns about contracts:
114 in favor, 12 opposed, and 3 abstaining
So, what you are seeing is a paper denying the existence of consensus, where the consensus was overwhelmingly in favor, published after the committee voted to approve recommendation of C++26, but before the ISO national bodies voted essentially as to whether they should accept that recommendation.
Given you thought there was not consensus, even though there was overwhelming consensus, how do you think other groups might have read that paper?
Clearly you read this paper and came to the conclusion that there was no consensus, because this paper is written in a way that makes you think that.
I got the claim of "no consensus" from the story we're commenting on, about how the standard wasn't accepted because of concerns over contracts. Given that every prior standard passed unanimously, that feels very notable to me.
I think maybe there was a miscommunication about what I meant by "consensus". I see that there was consensus within the committee (which P4433 also notes), but contracts are clearly still extremely controversial, or else we wouldn't be having this discussion.
Papers like this create the appearance of controversy due to the lack of supporting context.
The absolute opacity of the actual approval process after the recommendation from the technical committee does nothing to help the appearance of controversy where none exists.
There is clearly a controversy based on how many people involved with C++ are talking about this issue. Even bjarne is talking about it. They might be wrong but it is a thing that is happening and is still unresolved.
For what it's worth, the comments on the corresponding /r/cpp thread are probably worth reading through as well for more info/context and commentary from committee members.
refi64 | 13 hours ago
From looking around, it seems this was due to controversy regarding contracts? It almost seems like a political split going on there, with some people blaming the standards bodies and others blaming WG21 but all with somewhat fuzzy reasons. I'm curious if anyone has some info on the disagreements who isn't actually deep enough in this to have taken a side already?
EDIT: Okay wow, so there's P4334r0 which complains about contracts, a now-archived petition encouraging the DIS vote to fail, and P4433r0 (confusing numbering, much?) which argues that P4334r0 and the petition are incorrect. There's a lotta history here, huh...
[OP] mond | 13 hours ago
My understanding is that Bjarne has been going around trying to prevent contracts from going in. I think he's right on this one (even though I otherwise largely disagree with him wrt profiles), but it's very hard for me to tell whether blocking the standard with the national bodies is remotely worth it or proportional.
No clue what happens next! I assume the ideal would be that contracts get thrown out, then they redo the vote and the standard passes, and hopefully this happens relatively quickly? Worst case would be that there'll be no C++26?
david_chisnall | 12 hours ago
It’s complicated and I don’t fully understand it. Apparently individual member bodies can ratify and publish it, so what happens if ANSI ratifies it but ISO doesn’t? There’s now a C++26 but it isn’t an ISO standard. Fun times. If there is no ratified ISO standard, the current draft remains the working draft, so the next ISO standard will be based on it. There’s no process for accepting the standard with contracts removed.
I am one of the people strongly objected to contracts and regard it as a disaster for the language, but I gave up engaging (and did not vote in my national body vote) because I lost faith in the process as something able to produce a good outcome. My engagement is now very narrowly focused on trying to make sure that we have sensible definitions of pointer behaviour.
[OP] mond | 12 hours ago
My current guess (based on nothing) is that the draft will be sent back to WG21, has a chance to be amended (either removing or affirming contracts), and will then get another vote by the national bodies. Do you think that's likely?
Probably unrelated to this discussion, but I'd be interested to hear what you're working on here. Is this a pointer provenance thing? Is it about ensuring CHERI compatibility? I didn't know there's any "open discussions" on pointer behavior in C++, I figured most of this would be completely set in stone.
david_chisnall | 28 minutes ago
The core model is fairly uncontentious but there are other things like the semantics of
intprt_t. In C, it remains optional. C++ has made it mandatory but with implementation-defined semantics. I’m working (though haven’t updated the paper for a bit) on codifying the semantics to permit both what CHERI does and a slightly more lenient model.In particular, there are some simple things people expect. If you cast a pointer to an
intprt_tand add N, then cast back, the result should be the same as if you’d cast tochar*. This is not guaranteed by C or C++ but it’s such an obvious ‘of course it works that way’ thing that an implementation that didn’t preserve that property would not work for most non-trivial codebases. And, since compilers have to be able to do the right thing forchar*, all implementations can do that.Other arithmetic also needs to be defined in similar terms. In the CHERI C/C++ work, we found that the most common use of
intprt_twas to align pointers up and down. That use requires masking the low bits. Again, that should be defined because it’s currently 100% implementation-defined but people assume it works (we had to make it work with CHERI C/C++ because the other option was break everything).Beyond that, I want some feature-test macros that define whether arithmetic that takes the address to another object is defined. It doesn’t work in CHERI, but it is expected to in some low-level systems code (e.g. CPU-local storage in the FreeBSD kernel), so there needs to be a way for software to say ‘I assume this works, static assert fail if it doesn’t on thei target’.
refi64 | 13 hours ago
Oh wow, yes that seems quite severe. Looking more through some of these papers, I get some of the complaints for sure (mostly that relying on them for UB checks but then letting you turn them off is going to be a mess), but some of this wording seems like contracts are solely destructive. To be frank, the standards committees have been adding dysfunctional features for a long time, and sometimes they even later get fixed, so... I'm not sure if rounding up the international standards bodies here is a proportional action.
If Stroustrup is leading the fight against it, this does kinda seem more like a political fight, where some people who oppose it don't really want to be overridden on anything (and, perhaps, some in support wishing for the opposite).
[OP] mond | 13 hours ago
There are multiple papers and afaik talks on "why contracts are bad" , I'd look them up for references. Afaik a lot of stuff about the one definition rule, and "how do you selectively enable or disable contracts" etc. I'd look them up for references if you want to dive deeper.
That said, afaik there was "strong consensus" to get contracts in by the standard bodies.
I have not fully kept up on the current technical statusof the draft but Bjarne being actively involved (and against contracts) is afaik confirmed.
mort | 11 hours ago
I would be very interested to watch those talks on why contracts are bad. Do you remember a name, the speaker, the conference or anything else which could be used to find them?
olliej | 7 hours ago
Every complaint in P4334 had been brought to the committee, heard and considered, prior to voting to approve contracts in C++26. It is strange that the paper didn't acknowledge this, and the fact that you appear to believe that these complaints had not been considered is why ISO CoCs expect papers to contain relevant information like that.
It's very much a shame that a paper in this state was circulated in a way that continues to mislead readers into believing that the complaints had not already been heard and considered.
seb | 6 hours ago
@refi64 never said this. They literally link to a paper which says "WG21 has carefully considered each individual concern, weighed the trade-offs involved, and ultimately decided, in each case, in favour of the specification that is now in the C++26 DIS".
P4334 is useful for people like me who are out of the loop and want to understand where the disagreements lie with contracts. Clearly there's still no consensus, and plenty of people are very unhappy with contracts in their current state, and so it's nice to have some context on why that is. Just linking to a paper (alongside other papers showing the opposite side's stance!) doesn't imply that it hasn't been "heard and considered" by the committee.
olliej | 5 hours ago
Where are you getting this claim of no consensus then? Clearly you read this paper and came to the conclusion that there was no consensus, because this paper is written in a way that makes you think that.
To cite Herb Sutter's trip report[1] from croydon, first that "lack of consensus vote" to pull contracts into C++26:
And in 2026 the vote to approve C++ 26, with the inclusion of contracts
So, what you are seeing is a paper denying the existence of consensus, where the consensus was overwhelmingly in favor, published after the committee voted to approve recommendation of C++26, but before the ISO national bodies voted essentially as to whether they should accept that recommendation.
Given you thought there was not consensus, even though there was overwhelming consensus, how do you think other groups might have read that paper?
[1] https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/
seb | 4 hours ago
I got the claim of "no consensus" from the story we're commenting on, about how the standard wasn't accepted because of concerns over contracts. Given that every prior standard passed unanimously, that feels very notable to me.
I think maybe there was a miscommunication about what I meant by "consensus". I see that there was consensus within the committee (which P4433 also notes), but contracts are clearly still extremely controversial, or else we wouldn't be having this discussion.
olliej | 4 hours ago
They're not. They really really are not.
There is a group that does not want them.
Papers like this create the appearance of controversy due to the lack of supporting context.
The absolute opacity of the actual approval process after the recommendation from the technical committee does nothing to help the appearance of controversy where none exists.
wareya | 27 minutes ago
There is clearly a controversy based on how many people involved with C++ are talking about this issue. Even bjarne is talking about it. They might be wrong but it is a thing that is happening and is still unresolved.
aw1621107 | 11 hours ago
For what it's worth, the comments on the corresponding /r/cpp thread are probably worth reading through as well for more info/context and commentary from committee members.