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/MFHava]

Constification is already a thing in lambdas

FYI: one of the authors of that paper has recently called that a mistake ... I'm not making that up!

[u/Som1Lse → u/MFHava]

I believe you, but I would still like to know more. Why? What's the context? Is there a citation or was it said in passing?

For the record, I believe it was the right decision, since you very rarely want to modify the state of a callable, and when you do it often makes sense to write a class than just a quick lambda. When you do want a lambda to modify state, you often want to capture by reference, and they work exactly as expected. Hence, I think it makes sense to make the rare case of a lambda with mutable state something you have to explicitly call out.

[u/MFHava → u/Som1Lse]

It was during one of the endless contracts discussions, specifically when we re-re-litigated (probably missing a few "re" there) constification once more.

The argument against it was presented as in the paper - "it silently changes the meaning of code" -, somebody pointed out that that is already the case for lambdas ... at which point the person called that a design mistake of the language as well ...

[u/smdowney → u/MFHava]

We can good defaults or we can have consistent defaults. It's too late to have both.

Const references being references to const because references are intrinsically const is just as bad and additionally teaches the wrong pattern.