> What does guaranteed enforcement mean?
I'm not sure I can express it better than the proposal to add the corresponding feature [0]:
> This extension addresses the Romanian National Body's (NB) concern by enabling the writing of an individual contract assertion that guarantees the program execution will not continue past the contract assertion if it is violated, regardless of the semantics of other contract assertions. This addition to the C++26 Contracts facility allows reliable use of enforced contract assertions in large codebases with mixed contract semantics and also in hardened libraries.
> Is it worth the trade-offs?
Apparently some people/NBs feel quite strongly that it is.
> There's a reason why most code turns assert off in production and only does it in debug builds.
There's also a reason some codebases define asserts that aren't turned off in production in addition to debug-only asserts. The proposal lists multiple under Section 3.1 Existing Practice.
> and so if the code is trusted to work, you wouldn't want to check that it's working correctly.
Right, but sometimes you might think the consequences of such blind trust being misplaced are worse than the performance hit.
Static detection of impossible-to-satisfy contract conditions would be interesting, but as you say the technology is probably not ready for the kind of widespread use that inclusion in C++ would entail.
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39...
I'm not sure I can express it better than the proposal to add the corresponding feature [0]:
> This extension addresses the Romanian National Body's (NB) concern by enabling the writing of an individual contract assertion that guarantees the program execution will not continue past the contract assertion if it is violated, regardless of the semantics of other contract assertions. This addition to the C++26 Contracts facility allows reliable use of enforced contract assertions in large codebases with mixed contract semantics and also in hardened libraries.
> Is it worth the trade-offs?
Apparently some people/NBs feel quite strongly that it is.
> There's a reason why most code turns assert off in production and only does it in debug builds.
There's also a reason some codebases define asserts that aren't turned off in production in addition to debug-only asserts. The proposal lists multiple under Section 3.1 Existing Practice.
> and so if the code is trusted to work, you wouldn't want to check that it's working correctly.
Right, but sometimes you might think the consequences of such blind trust being misplaced are worse than the performance hit.
Static detection of impossible-to-satisfy contract conditions would be interesting, but as you say the technology is probably not ready for the kind of widespread use that inclusion in C++ would entail.
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39...