Date: Mon, 20 Oct 2025 20:27:39 -0700
Ryan is exactly right. Hand-written contracts give statistical (aka incremental) safety by construction: The more contracts you write, the more functional safety you have. It’s not a guarantee, it’s a knob you can dial.
This distinction is so fundamental to understanding contracts that I made it the first non-intro slide in the only contracts talk I’ve ever given (a month ago <https://www.youtube.com/watch?v=oitYvDe4nps> ): “Functional safety (vs. memory safety)”.
That slide adds something important (IMO) to what Ryan said (Ryan, sorry if you said it and I missed it): how contracts are related to memory safety guarantees.
That relationship in a nutshell: Contracts can be used to get actual memory safety guarantees, not when they are written by hand, but rather when they are generated by language guarantees that are implemented-in-terms-of contracts as an implementation detail (e.g., a hypothetical rule like “deferencing a null pointer is checked as-if contract_assert(ptr) was written before the dereference). Such a language rule ensures the contracts are injected systematically by construction without relying on the user to write those contracts. Then it is not the contracts that are giving the memory safety guarantees, it is the language rules… but those can use the same contracts that the user can additionally write on their own to supplement the ones the language writes. That’s a powerfully cohesive model. And once we have labels, we can absolutely directly specify such standard lang/lib rules if we want, including the stdlib hardening rules.
FWIW, none of this is new: We said the same thing several times in Hagenberg EWG discussion (I said it, and others did too).
Pasting that slide for convenience, which says all the above:
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ryan McDougall via SG15
Sent: Monday, October 20, 2025 7:42 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Ryan McDougall <mcdougall.ryan_at_[hidden]>; sg15_at_[hidden]; sg21_at_[hidden]; Tom Honermann <tom_at_[hidden]>; John Spicer <jhs_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
Assurance is based on redundant checking -- of everything -- contracts, hardware, compilers, static analysis, etc. Whatever is checked, it's checked more than once in more than one way. The whole point is that when that's all done, you're "bug free" (in a statistical sense).
Therefore any bugs caused by either the expression in the contract statement, or in the programmer's understanding of build modes, or the build engineer's understanding of the programmer's code, or a bug in the compiler itself -- you name it -- are statistically not not possible in the long run.
Let me give you an example: let's say a check is incorrectly ignored as per P3835 -- this is not a problem for Functionally Safe processes. Why? Let's say the incorrectly ignored check checks for nullptr. The program now has UB (like so many C++ programs).
Yet somehow, when the program runs all its unit tests -- against the odds -- the UB does not cause any unit tests to fail! And somehow against the odds the UB does not cause any integration test to fail! And somehow against the odds the UB does not cause any system tests to fail! And somehow against the odds the UB does not cause the fuzzing tests to fail! Oh my.
But we're Safety Critical, so we don't stop there: we now have millions of real world hours of simulation to run. And after that we have thousands of real world hours of real world environmental testing to run. Our UB eventually manifests, long before it was unsafe, and a fix is merged immediately. Done.
The odds that our null pointer check was a valid code path and did not exhibit any failure is vanishingly small. This is what I mean when I say we have decades of experience -- this is why your plane doesn't fall out of the sky.
So -- Tom's point is that contract checking helps, but is in no way sufficient for Functional Safety -- it's all that testing that's important for Functional Safety. Functional Safety is a **process** that's implemented by an **organization** -- and P2900 makes that easier for them, and it's better than macros.
Cheers,
On Mon, Oct 20, 2025 at 7:15 PM Gabriel Dos Reis <gdr_at_[hidden] <mailto:gdr_at_[hidden]> > wrote:
[Ryan]
* Contracts -- macro or P2900 -- are one of those best practices.
Then, let’s me rephrase my question: How does P2900 supports “implementing best practices that drive towards a statistical level of assurance” without one depending “on contract checks as a foundational aspect of [that] functional safety”?
* Language Safety is also one of those best practices -- however -- while somewhat necessary, Language Safety is definitely not remotely sufficient.
You might be right, but let’s not distract ourselves into “language safety” label just yet. Let’s focus on what can be me understand the various statements being put forward.
-- Gaby
From: Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> >
Sent: Monday, October 20, 2025 6:59 PM
To: sg15_at_[hidden] <mailto:sg15_at_[hidden]>
Cc: sg21_at_[hidden] <mailto:sg21_at_[hidden]> ; Gabriel Dos Reis <gdr_at_[hidden] <mailto:gdr_at_[hidden]> >; Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]> >; John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> >
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
No *feature* ever achieves Functional Safety -- an organization does when they implement best practices that drive towards a statistical level of assurance.
Contracts -- macro or P2900 -- are one of those best practices. P2900 is regarded by man as an improvement over macros by those who work in this space. P2900 (or something very similar) helps companies implement best practices more efficiently, not to mention the ecosystem for static (or AI) analysis.
Language Safety is also one of those best practices -- however -- while somewhat necessary, Language Safety is definitely not remotely sufficient.
On Mon, Oct 20, 2025 at 6:26 PM Gabriel Dos Reis via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden]> > wrote:
[Tom]
* If you are depending on contract checks as a foundational aspect of your functional safety, then you have not achieved functional safety.
Interesting. How do contracts (as in P2900) achieve functional safety?
-- Gaby
From: SG15 <sg15-bounces_at_[hidden] <mailto:sg15-bounces_at_[hidden]> > On Behalf Of Tom Honermann via SG15
Sent: Monday, October 20, 2025 5:43 PM
To: sg21_at_[hidden] <mailto:sg21_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]> >; sg15_at_[hidden] <mailto:sg15_at_[hidden]> ; John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> >; Contracts SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> >
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
On Oct 20, 2025, at 4:56 PM, John Spicer via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
Macros are different from contracts because:
1. You can make sure that you get consistent behavior when the contracts are in headers (the mail topic of this thread).
2. You can choose whether or not exceptions are mapped into contract violations
3. You can choose the violation handler that you want to be used
4. Expressions silently change meaning (constification)
5. Because of #2, you don’t necessarily end up with massive code for each contract check
6. Different pieces of code can use different semantics in a transparent mechanism.
They don’t address the needs of Functional Safety because you don’t know whether they will actually be checked in any given case.
If you are depending on contract checks as a foundational aspect of your functional safety, then you have not achieved functional safety.
Tom.
John.
On Oct 20, 2025, at 4:08 PM, Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> > wrote:
They are comparable because they both address the needs of Functional Safety as per p3578 <http://wg21.link/p3578> . SG23 took a poll on whether they're better than macros see P3297 <http://wg21.link/P3297> .
I think it's not a leap of logic that EWG has strong consensus to pass P2900 precisely because they feel it's strictly better than macros.
Cheers,
On Mon, Oct 20, 2025 at 12:58 PM John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> > wrote:
We have never taken a poll of whether P2900 is better then macro solutions.
Could you explain why you think contracts and macro-based solutions are comperable?
John.
On Oct 20, 2025, at 3:09 PM, Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> > wrote:
I’m saying we have decades of experience with macro based systems, which defines the floor of features/expectations. The consensus is P2900 is better taken as a whole. There are things i think should be different with p2900, but p2900 represents consensus. There has been no evidence put forward that there is a more correct course. Based on those decades of experience here are no outstanding questions that having a TS would answer.
If i am wrong, please list precise questions that a TS would answer. “We don’t have enough experience” is a statement.
Cheers,
On Mon, Oct 20, 2025 at 11:54 AM John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> > wrote:
You keep saying things like we have “decades of experience with macro-based systems”.
If contracts were remotely similar to macro-based systems, we would not be having this discussion.
The problem is that contracts are *vastly* different.
If you put P2900 and macro-based systems in the same set, that means you don’t understand one or the other.
John.
On Oct 20, 2025, at 2:22 PM, Ryan McDougall via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
The "course corrections" do not actually suggest a future course (beyond asserting without evidence"we need more experience" and kicking the can down the road to a TS) -- we've had years for alternative proposals to be put forward, and none have surpassed P2900.
We *do* have decades of experience with macro-based systems, we *do* have decades of experience building software at scale (see Software Engineering at Google <https://abseil.io/resources/swe-book> ), and we *do* know who our users are (see P1995 and P3297) -- and while there are many variations on contracts, P2900 represents our best consensus interpretation of those decades of experience. Not all of these decisions were everyone's first choice, but P2900 is the consensus. There is no evidence that any other option would improve that.
Multiple papers, like P2900 and P3578 <http://wg21.link/p3578> explain exactly who the feature is for, and how and why each of these design choices were made. There is no reason to believe the current course is incorrect, or that another course would be more correct.
On Mon, Oct 20, 2025 at 4:58 AM Ville Voutilainen via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
On Mon, 20 Oct 2025 at 14:34, Timur Doumler via SG15
<sg15_at_[hidden] <mailto:sg15_at_[hidden]> > wrote:
> Given the above, it seems to me like opposing C++26 contract assertions because you want that checks are always on / always enforced is kinda like this:
>
> – Alice: "I want safer roads for pedestrians." (reasonable and good request)
> – Bob: "Here's a proposal to fund bike lanes in the city." (reasonable and good proposal roughly in the same area but with a different goal)
> – Alice: "But bike lanes don't add more crosswalks or reduce speed limits. So they don't make roads safer for pedestrians. Therefore, we should not build bike lanes."
>
> Here, Alice is committing a logical fallacy. Just because bike lanes are not useful for Alice, it doesn't mean that they're not useful for Bob, and taking away bike lanes from Bob does nothing to give Alice what she wants.
The colorful analogy doesn't include considerations where providing
bike lanes for Bob and doing nothing else is not entirely harmless for
the pedestrians Alice is focused on.
It's also incorrect in its suggestion that bike lanes are not useful
for Alice. Nobody has said that P2900 isn't useful. That's why it's
included
in *every* *single* *one* of the currently active proposals suggesting
course corrections.
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11436.php
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11499.php
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11532.php
_______________________________________________
SG15 mailing list
SG15_at_[hidden] <mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
This distinction is so fundamental to understanding contracts that I made it the first non-intro slide in the only contracts talk I’ve ever given (a month ago <https://www.youtube.com/watch?v=oitYvDe4nps> ): “Functional safety (vs. memory safety)”.
That slide adds something important (IMO) to what Ryan said (Ryan, sorry if you said it and I missed it): how contracts are related to memory safety guarantees.
That relationship in a nutshell: Contracts can be used to get actual memory safety guarantees, not when they are written by hand, but rather when they are generated by language guarantees that are implemented-in-terms-of contracts as an implementation detail (e.g., a hypothetical rule like “deferencing a null pointer is checked as-if contract_assert(ptr) was written before the dereference). Such a language rule ensures the contracts are injected systematically by construction without relying on the user to write those contracts. Then it is not the contracts that are giving the memory safety guarantees, it is the language rules… but those can use the same contracts that the user can additionally write on their own to supplement the ones the language writes. That’s a powerfully cohesive model. And once we have labels, we can absolutely directly specify such standard lang/lib rules if we want, including the stdlib hardening rules.
FWIW, none of this is new: We said the same thing several times in Hagenberg EWG discussion (I said it, and others did too).
Pasting that slide for convenience, which says all the above:
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ryan McDougall via SG15
Sent: Monday, October 20, 2025 7:42 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Ryan McDougall <mcdougall.ryan_at_[hidden]>; sg15_at_[hidden]; sg21_at_[hidden]; Tom Honermann <tom_at_[hidden]>; John Spicer <jhs_at_[hidden]>
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
Assurance is based on redundant checking -- of everything -- contracts, hardware, compilers, static analysis, etc. Whatever is checked, it's checked more than once in more than one way. The whole point is that when that's all done, you're "bug free" (in a statistical sense).
Therefore any bugs caused by either the expression in the contract statement, or in the programmer's understanding of build modes, or the build engineer's understanding of the programmer's code, or a bug in the compiler itself -- you name it -- are statistically not not possible in the long run.
Let me give you an example: let's say a check is incorrectly ignored as per P3835 -- this is not a problem for Functionally Safe processes. Why? Let's say the incorrectly ignored check checks for nullptr. The program now has UB (like so many C++ programs).
Yet somehow, when the program runs all its unit tests -- against the odds -- the UB does not cause any unit tests to fail! And somehow against the odds the UB does not cause any integration test to fail! And somehow against the odds the UB does not cause any system tests to fail! And somehow against the odds the UB does not cause the fuzzing tests to fail! Oh my.
But we're Safety Critical, so we don't stop there: we now have millions of real world hours of simulation to run. And after that we have thousands of real world hours of real world environmental testing to run. Our UB eventually manifests, long before it was unsafe, and a fix is merged immediately. Done.
The odds that our null pointer check was a valid code path and did not exhibit any failure is vanishingly small. This is what I mean when I say we have decades of experience -- this is why your plane doesn't fall out of the sky.
So -- Tom's point is that contract checking helps, but is in no way sufficient for Functional Safety -- it's all that testing that's important for Functional Safety. Functional Safety is a **process** that's implemented by an **organization** -- and P2900 makes that easier for them, and it's better than macros.
Cheers,
On Mon, Oct 20, 2025 at 7:15 PM Gabriel Dos Reis <gdr_at_[hidden] <mailto:gdr_at_[hidden]> > wrote:
[Ryan]
* Contracts -- macro or P2900 -- are one of those best practices.
Then, let’s me rephrase my question: How does P2900 supports “implementing best practices that drive towards a statistical level of assurance” without one depending “on contract checks as a foundational aspect of [that] functional safety”?
* Language Safety is also one of those best practices -- however -- while somewhat necessary, Language Safety is definitely not remotely sufficient.
You might be right, but let’s not distract ourselves into “language safety” label just yet. Let’s focus on what can be me understand the various statements being put forward.
-- Gaby
From: Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> >
Sent: Monday, October 20, 2025 6:59 PM
To: sg15_at_[hidden] <mailto:sg15_at_[hidden]>
Cc: sg21_at_[hidden] <mailto:sg21_at_[hidden]> ; Gabriel Dos Reis <gdr_at_[hidden] <mailto:gdr_at_[hidden]> >; Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]> >; John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> >
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
No *feature* ever achieves Functional Safety -- an organization does when they implement best practices that drive towards a statistical level of assurance.
Contracts -- macro or P2900 -- are one of those best practices. P2900 is regarded by man as an improvement over macros by those who work in this space. P2900 (or something very similar) helps companies implement best practices more efficiently, not to mention the ecosystem for static (or AI) analysis.
Language Safety is also one of those best practices -- however -- while somewhat necessary, Language Safety is definitely not remotely sufficient.
On Mon, Oct 20, 2025 at 6:26 PM Gabriel Dos Reis via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden]> > wrote:
[Tom]
* If you are depending on contract checks as a foundational aspect of your functional safety, then you have not achieved functional safety.
Interesting. How do contracts (as in P2900) achieve functional safety?
-- Gaby
From: SG15 <sg15-bounces_at_[hidden] <mailto:sg15-bounces_at_[hidden]> > On Behalf Of Tom Honermann via SG15
Sent: Monday, October 20, 2025 5:43 PM
To: sg21_at_[hidden] <mailto:sg21_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]> >; sg15_at_[hidden] <mailto:sg15_at_[hidden]> ; John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> >; Contracts SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> >
Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries
On Oct 20, 2025, at 4:56 PM, John Spicer via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
Macros are different from contracts because:
1. You can make sure that you get consistent behavior when the contracts are in headers (the mail topic of this thread).
2. You can choose whether or not exceptions are mapped into contract violations
3. You can choose the violation handler that you want to be used
4. Expressions silently change meaning (constification)
5. Because of #2, you don’t necessarily end up with massive code for each contract check
6. Different pieces of code can use different semantics in a transparent mechanism.
They don’t address the needs of Functional Safety because you don’t know whether they will actually be checked in any given case.
If you are depending on contract checks as a foundational aspect of your functional safety, then you have not achieved functional safety.
Tom.
John.
On Oct 20, 2025, at 4:08 PM, Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> > wrote:
They are comparable because they both address the needs of Functional Safety as per p3578 <http://wg21.link/p3578> . SG23 took a poll on whether they're better than macros see P3297 <http://wg21.link/P3297> .
I think it's not a leap of logic that EWG has strong consensus to pass P2900 precisely because they feel it's strictly better than macros.
Cheers,
On Mon, Oct 20, 2025 at 12:58 PM John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> > wrote:
We have never taken a poll of whether P2900 is better then macro solutions.
Could you explain why you think contracts and macro-based solutions are comperable?
John.
On Oct 20, 2025, at 3:09 PM, Ryan McDougall <mcdougall.ryan_at_[hidden] <mailto:mcdougall.ryan_at_[hidden]> > wrote:
I’m saying we have decades of experience with macro based systems, which defines the floor of features/expectations. The consensus is P2900 is better taken as a whole. There are things i think should be different with p2900, but p2900 represents consensus. There has been no evidence put forward that there is a more correct course. Based on those decades of experience here are no outstanding questions that having a TS would answer.
If i am wrong, please list precise questions that a TS would answer. “We don’t have enough experience” is a statement.
Cheers,
On Mon, Oct 20, 2025 at 11:54 AM John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]> > wrote:
You keep saying things like we have “decades of experience with macro-based systems”.
If contracts were remotely similar to macro-based systems, we would not be having this discussion.
The problem is that contracts are *vastly* different.
If you put P2900 and macro-based systems in the same set, that means you don’t understand one or the other.
John.
On Oct 20, 2025, at 2:22 PM, Ryan McDougall via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
The "course corrections" do not actually suggest a future course (beyond asserting without evidence"we need more experience" and kicking the can down the road to a TS) -- we've had years for alternative proposals to be put forward, and none have surpassed P2900.
We *do* have decades of experience with macro-based systems, we *do* have decades of experience building software at scale (see Software Engineering at Google <https://abseil.io/resources/swe-book> ), and we *do* know who our users are (see P1995 and P3297) -- and while there are many variations on contracts, P2900 represents our best consensus interpretation of those decades of experience. Not all of these decisions were everyone's first choice, but P2900 is the consensus. There is no evidence that any other option would improve that.
Multiple papers, like P2900 and P3578 <http://wg21.link/p3578> explain exactly who the feature is for, and how and why each of these design choices were made. There is no reason to believe the current course is incorrect, or that another course would be more correct.
On Mon, Oct 20, 2025 at 4:58 AM Ville Voutilainen via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]> > wrote:
On Mon, 20 Oct 2025 at 14:34, Timur Doumler via SG15
<sg15_at_[hidden] <mailto:sg15_at_[hidden]> > wrote:
> Given the above, it seems to me like opposing C++26 contract assertions because you want that checks are always on / always enforced is kinda like this:
>
> – Alice: "I want safer roads for pedestrians." (reasonable and good request)
> – Bob: "Here's a proposal to fund bike lanes in the city." (reasonable and good proposal roughly in the same area but with a different goal)
> – Alice: "But bike lanes don't add more crosswalks or reduce speed limits. So they don't make roads safer for pedestrians. Therefore, we should not build bike lanes."
>
> Here, Alice is committing a logical fallacy. Just because bike lanes are not useful for Alice, it doesn't mean that they're not useful for Bob, and taking away bike lanes from Bob does nothing to give Alice what she wants.
The colorful analogy doesn't include considerations where providing
bike lanes for Bob and doing nothing else is not entirely harmless for
the pedestrians Alice is focused on.
It's also incorrect in its suggestion that bike lanes are not useful
for Alice. Nobody has said that P2900 isn't useful. That's why it's
included
in *every* *single* *one* of the currently active proposals suggesting
course corrections.
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11436.php
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11499.php
_______________________________________________
SG21 mailing list
SG21_at_[hidden] <mailto:SG21_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11532.php
_______________________________________________
SG15 mailing list
SG15_at_[hidden] <mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
- text/html attachment: attachment
- image/png attachment: image001.png
Received on 2025-10-21 03:27:44