You say "even if P2900 does not fix linking issues that are not inherent to Contracts”, but the point of P3835 is that the issues *are* inherent to contracts.

The reason for this is that if you currently use a macro like MY_LIB_ASSERT(x), then you have control over what it does, even when your header is used by someone else. If you fail to get this right, it is an ODR violation. So you have done something that makes your program ill-formed, and your tools might be able to detect this.

But if you use contracts, it is not an ODR violation, even when the functions end up doing different things.

So, contracts introduce a new problem that other mechanisms, including C assert, do not have.

John, are you opposed to implementations offering an option to specify the contract checking semantic at link-time, load-time or run-time as opposed to compile-time? Other language offer at least some such flexibility; for example, Java assertion enablement is decided at load-time.

One of the many things I appreciate about P2900 is that it takes the pressure off of the programmer to decide whether or not to write a contract assertion; they can freely author them with the understanding that someone else will choose the appropriate strategy for enabling them based on deployment scenario. I believe that flexibility is more important to the success of Contracts than the ability to guarantee that any particular assertion will always be evaluated with a particular semantic (and P3290 (Integrating Existing Assertions With Contracts) and P3400 (Specifying Contract Assertion Properties with Labels) will provide a solution for those that want such a guarantee for a specific contract assertion).

Perhaps the primary concern is that P2900 contracts does not expose a feature that suffices, without other implementation provided guarantees, to implement a hardened interface similar to what C++26 now offers thanks to P3471 (Standard Library Hardening)?

Tom.

John.

On Oct 13, 2025, at 5:21 PM, Ryan McDougall via SG21 <sg21@lists.isocpp.org> wrote:

Let's be very specific with our words -- "okay" and "safe" are not well defined terms with which we can make sound engineering decisions.

I did not claim that programs which may have UB are "okay" -- I'm saying that for decades we have made programs that may have UB to be made "Functionally Safe"" -- because "Functional Safety" does not depend on language guarantees. As p3578r1 explains, we got humans to the moon with assembly language. "Functional Safe" depends on Assurance -- ie. highly rigorous and structured testing.

While contracts can *help* Language Safety, Contracts do not need to be "Language Safe". Complaints that contracts are not "Language Safe" are misplaced. Contracts are a strict improvement for "Functional Safety" and that's justification enough -- even if P2900 does not fix linking issues that are not inherent to Contracts.

On Mon, Oct 13, 2025 at 1:20 PM John Spicer via SG15 <sg15@lists.isocpp.org> wrote:

I certainly hold Ryan in high regard, but I don’t understand how the situation described in P3835 can be considered “okay”.

As P3835 says, the library with l1.cpp is built with the quick_enforce semantic. c1.cpp is compiled with the ignore semantic.

If the line in red is removed, the program will fail the assertion. If the line in red is present, the program might not fail the assertion.

Maybe Ryan and you are okay with that behavior.

I’m not.

John.

file: z.h

inline void f(int x) {
	contract_assert(x > 0);
}

file: l1.cpp

#include "z.h"

void g() {
	f(0); // expected to fail contract
}

file: c1.cpp

#include "z.h"

extern void g();

int main() {
	f(1); // expected to pass contract
	g();
}

On Oct 13, 2025, at 2:48 PM, Gideon Mueller via SG21 <sg21@lists.isocpp.org> wrote:

100% agree with what Ryan wrote!

I fail to see how  “the problem” stated in P3835 is specific to contracts and why a contracts /MVP/ should be considered responsible for solving it. If it got covered in the email thread I missed it, could the authors please expand on this or point to where they did?

PS: maybe the issue is on my end, but I am unable to access https://contracts.efcs.ca/#contract-groups, does anyone have an alternative link?

Regards

Gideon

From: SG21 <sg21-bounces@lists.isocpp.org> on behalf of Ryan McDougall via SG21 <sg21@lists.isocpp.org>
Date: Sunday, 5. October 2025 at 21:01
To: sg15@lists.isocpp.org <sg15@lists.isocpp.org>
Cc: Ryan McDougall <mcdougall.ryan@gmail.com>, SG21 Contracts <sg21@lists.isocpp.org>
Subject: Re: [isocpp-sg21] [isocpp-sg15] P3835 -- Different contract checking for different libraries

External email: Use caution opening links or attachments

I'm always disappointed with phrasing like "is not safe" or "not viable in the real world", because invariably the speakers do not show a working definition of "safe" and lack experience in safety critical software -- this puts the burden of education on one side, which ends up in volumes of pages that are simply never read.

They most certainly haven't read P3297 C++26 Needs Contract Checking -- which was approved by SG23 in St Louis -- nor P3578 What is "Safety"? which actually defines the "safety" with precision and clarity. We have been talking about this since P1517 Contract Requirements for Iterative High-Assurance Systems.

P2900 is "Safe", according to P3578 -- which itself follows decades of industry practice -- and is the reason you arrive at WG21 meetings alive. P2900 is "viable", because the industry has been using macro-based checks in our software since before most of us were programmers. To say the contrary is simply not sustainable.

If you want to have different checks on different "components", then this is a matter of library design -- something we've been doing for decades: compile the TUs you want with semantic X into a static library, and semantic Y into another static library, and then link the two together. Software design -- done.

P2900 is the result of one of the most rigorous design processes I've ever witnessed at WG21, and P2900 is intended to be a minimum viable product that adheres to a collection of use cases laid out in P1995 Contract Use cases from 2020. It has been derided as both not minimal enough, and overly complicated -- yet no one bothers to do a counter analysis to come to different conclusions. There are reams of pages in the papers that lead to P2900, but the pagers in the papers running counter are scant, hand-wavy, and abuse decades of industry standard jargon.

P2900 is safe, and is viable -- and no one has yet presented a serious argument to the contrary.

Cheers, 

On Thu, Oct 2, 2025 at 1:31 PM Andrzej Krzemienski via SG15 <sg15@lists.isocpp.org> wrote:

pon., 29 wrz 2025 o 22:14 John Spicer via SG21 <sg21@lists.isocpp.org> napisał(a):

I think that compile-time and link-time selection of semantics is a desirable feature.

But that misses the essential point of p3835r0 that the semantics need to apply to software “components” and not to translation units or to the entire program.

If you consider the example in the paper I referenced, it is essential that the check in l1.cpp fail.

There could be some other contract check in c1.cpp that is expected to be ignored.

The key issue is not, IMO, how you control a “checking mode” that applies to a TU or the program, the issue is how you apply various “checking modes” to different components (e.g., libraries).

There are a number of possible solutions to this problem, each of which have their own tradeoffs.

But the first step is the recognition that this is a problem that needs to be solved in order for contracts to be viable in the real world.

I would like to understand this expectation a bit more. Rather than talking about the details I would focus on the motivation. 

The scenario that I am familiar with is that when a program P uses a library L, it is likely that P will use L incorrectly, and additional measures need to be taken to test if P is using L correctly. This would mean that in the P2900 world we would want to runtime check the assertions *at the library boundary* but not necessarily *inside* the library. IOW, If I were the author of P, I would trust library L that it was thoroughly tested, and would not want to assertion-test its implementation. But I would like to test if I am *using* the library correctly. So I would like to enable every precondition in L's interface and some contract_asset statements close to library entry points that also function as preconditions. But only those. If libstdc++'s STL implementation offers control macros to enable STL-specific assertions, those assertions practically check if the user is using the STL correctly: not if STL has been correctly implemented.

But P3835 seems to be expressing a different need. So my question to the authors of P3835 is: is your motivating use case testing the library *usage* or really testing one library's implementation in a different way than another library's implementation? If it is the latter, that would be strange: you would have to mistrust the library L enough to want to keep checking its implementation, but at the same time trust it enough that the author put the right assertions in the right places with sufficient density.

Regards,

&rzej;

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG21 mailing list
SG21@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11233.php

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG21 mailing list
SG21@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11237.php

_______________________________________________
SG21 mailing list
SG21@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2025/10/11243.php