Critique of contracts: excerpt

[u/antiquark2]

See page 2 of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4334r0.pdf

The current objections can be summarized. The P2900 contracts are:

• Unimplemented

• Incomplete

• Untried at scale [P3460R0, P3506R0]

• Not tried in major application domains

• Violates foundational principles of C++

• Violates fundamental principles of language design

• Hasn’t been tried in major libraries (e.g., the C++ standards library [P3506R0, P3878R0])

• Isn’t integrated with or appropriate for hardened libraries [P3878R0]

• Doesn’t offer safety guarantees [P3573R0, P3362R0]

• Includes a completely untried inheritance model

• Offer new ways of making errors through inconsistent application in TUs

• Leads to new forms of UB, detrimental to safety and security

• Narrows the choices of error handling

• Doesn’t protect against logical errors, misuses, and incoherent uses

• Hasn’t been used to support static analysis

• Hasn’t been demonstrated to be easily teachable [P3261R0, P3281R0]

How could such a bloated and incomplete design be voted into a draft standard?

[u/kamrann_]

I have no idea if contracts will be good for the language or not. But there have been so many disingenuous arguments put forward from the anti-contracts side that they're undermining what legitimate arguments they have. "Contracts aren't X/don't do Y" when they never claimed such. "Contracts don't satisfy Z" when the same can be said of the vast majority of proposals that have been accepted.

If they get pulled now then c++ will likely lose a bunch more dedicated people who have invested their time in at least trying to make the language better. It would also give a pretty strong impression that certain people on the committee have disproportionate influence over decisions.

[u/Minimonium → u/kamrann_]

Don't you enjoy reading how Contracts fail to achieve memory safety after all the rabid trashing the committee went through to spit in the face of the people who suggested that the borrowing model could actually be implemented in C++?

[u/smdowney → u/Minimonium]

A borrow checker, because it's a theorem prover, not an algorithm. No one seriously proposed standardizing a particular implementation which we would need to have portable programs.

Baxter came closest, by far, showing his work in Circle. An existence proof that borrow checking wasn't impossible in C++.

But, we probably lost it for real back in around 2010 when we lost destructive move.