I think "guaranteed contract enforcement" should be added to item D since that is explicitly called out as the only technical proposal that would change some NB votes from no to yes.
If, on the other hand, you mean only that, regardless of the status of a contract, if the compiler can detect that it would be violated, it must have failed to compile, I guess that would be all for that. On the other hand, the state of theorem provers that are able to prove things will and won't work is ... evolving. There will a lot of people be frustrated when they upgrade their compiler to a minor point release and suddenly a lot of code fails to compile because it always was broken but likely in an obscure situation that never happens in the real world.
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...
And now I'm even more confused. Why is this so critical that we can't say we're going to put it in another next version of the standard? Compile is regularly see things in the future version of standards and them implement early. I'm not disagreeing with the paper. I'm disagreeing that this is so critical it needs to abort the whole process.
The only red-string-on-a-cork-board I can connect is between guaranteed enforcement and the design decision that "contract assertions must not be used for error handling and input validation". The latter would seem to rule out guaranteed enforcement now and in the future and EWG apparently voted against P3911 back in January [0], so perhaps they think that they won't ever see guaranteed enforcement if contracts is left in the standard as-is.
That's all quite speculative, though, so take that with an appropriately-sized grain of salt/
[0]: https://github.com/cplusplus/papers/issues/2536#:~:text=Dire...
This feature was first proposed in 2004. In 2018, they were added to the draft of the standard, and then removed in 2019. So that already has been happening, for over a decade.
Part of the reason this is coming to a head is that it's already been a long time. Another reason is that some see contracts as fitting into the safety story for C++. Part of it is because, well, standards are done by the people that show up, and the people who show up care about this.
> I'm disagreeing that this is so critical it needs to abort the whole process.
It's a byproduct of how the process works. There are a series of votes, and they're not done by the same people. Some people voted yes to put them in, and then the vote after involved people voting no, they don't think they're good enough to put in. It is not so much that "this is so critical that it needs to abort the whole process," so much as it is "the final vote is the time when those people get to express their support or dissent." One of the proposals in the paper is that they could remove this feature, and then the rest would likely move forward. It will only hold up the entire thing if the people who are pro this feature landing decide that it's worth holding everything else up for.
More and more I'm on the side of those who are point at the 'no' votes as babies who can't work together. This is not a new thing and your preferred action isn't the best compromise, grow up. I know that is insulting, but it seems well deserved
I have a feeling that the paper isn't even a good way to solve their problem, but I can't quite figure out what would be better.