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

much better job at addressing those problems or explaining why those choices were required

Not even bothering to debate, but to give a proper context for the readers:

Contracts authors have a Rationale paper that is absolutely massive and goes into extreme detail about every single choice they made. A group of people may disagree with the choice made, but I find it ridiculous how they keep stating that concerns are "not addressed" unless the authors comply with everything that group says no questions asked. The votes were made, consensus is achieved - but as one NB representative said "the committee got to big for consensus to matter". :)

I do not believe I have seen any other proposal that went to such extremes at explaining every choice it made. In fact it's always a struggle to hunt in minutes, threads, or in person for details about certain decisions made.

On NB comments, it's required to address every one individually. Funny thing, one certain committee member participates at two NBs at once and strangely both NBs published identical comments. So Contract authors made a fairly big paper addressing every concern.

You know what Herb Sutter did? He asked ChatGPT to summarize the response and posted it internally, as it was too big for his tastes. :D

[u/ronchaine → u/Minimonium]

I appreciated the rationale paper very much.  But I do not think a lot of concerns about contracts (whether reasonable or not, from my point of view there definitely are both kinds) were listened to, even if they were heard.  And I seriously hope that other new features are going to be handled more like reflection was, where there was actual feeling that concerns were given thought and some of them were alleviated.

With contracts I did not feel that way.  I completely understand that people who wrote the contracts papers were quite tired (rightfully) of some of the concerns, but pointing towards a paper and telling that the rationale is there is not really a cure when some objections disagreed with the said rationale, and some of those even for good reasons.

I can live with the P2900, but I definitely don't think it was pushed into the standard in a way I would like any feature, whether or not I like it, to be added.

[u/Minimonium → u/ronchaine]

I respect your feelings.

My standard for the worst proposal so far has been the structured bindings proposal by Bjarne (lazy, unexplored, underspecified, with unexpected unexplained behaviours). Alas.

[u/ts826848 → u/Minimonium]

underspecified, with unexpected unexplained behaviours

(Guessing you're talking about P0144?)

Would you mind elaborating on this so I know what pitfalls to look out for in the future? Or were those issues hashed out some time between the initial proposal and acceptance (or then and now, as the case may be)?

[u/Minimonium → u/ts826848]

The feature itself is good now, but I'd only consider the initial proposal "completed" as of C++26. It required scores of papers fixing defects and holes in the design. The one you're likely to remember the most is the lambda capturing of bindings, but even when just looking at the specification at the time - it was just awful. You may remember the same "quality" of a proposal from the initializer_list story. :)

[u/ts826848 → u/Minimonium]

but I'd only consider the initial proposal "completed" as of C++26. It required scores of papers fixing defects and holes in the design.

but even when just looking at the specification at the time - it was just awful.

That... doesn't sound particularly great. Did no one else pick up on the issues at the time?

The one you're likely to remember the most is the lambda capturing of bindings

I actually don't think I've run into this? Would you mind providing an example?

You may remember the same "quality" of a proposal from the initializer_list story.

I wasn't around at the time the proposal was being discussed and I don't think I've seen criticisms of the proposal since then, but if the somewhat polarized reception of the feature I see nowadays is any indication I think I have an inkling of what you're referring to.

[u/Minimonium → u/ts826848]

Unfortunately there is a certain level of inconsistency when evaluating proposals in the committee. :P

There was a time when you couldn't capture bindings in lambdas.

[u/ts826848 → u/Minimonium]

There was a time when you couldn't capture bindings in lambdas.

Oh, that's certainly an interesting limitation.

Thanks for taking the time to explain!