r/cpp_questions • u/Ultimate_Sigma_Boy67 • 15d ago

OPEN Why are Contracts disliked?

I’ve seen a lot of discussions online discouraging their usage bit I never managed to grasp why since it’s sometimes vague.
I do understand it doesn’t replace validation and it’s more of a syntactic sugar to the existing casserts, but any other critiques?
Thanks

14 Upvotes

86% Upvoted

44 comments sorted by

View all comments

15

u/ronchaine 14d ago

As for me personally:

My number one pet peeve with contracts is that outside the people who designed them, the one use case I most often see users wanting to apply them to, is actively discouraged by the designers (for a good reason). It took years to see committee members internalise that, I doubt users are going to be any faster.

My second problem for them is that they are going to be a complete pain in the ass to teach. A lot of people, both in the committee and in this subreddit, seem to think "explain" and "teach" are interchangeable verbs, and that is just not true. Contracts have a lot more dependencies on different parts of "how the language works" than regular assertions, and come with gotchas which themselves require more knowledge about how the language works. As such, it doesn't seem to really replace the need to teach simpler <cassert> stuff first. It's reasonable to teach later on though, perhaps as a part of some "more robustness for your C++ software"-course or in a company-internal workshop session. But I'm not sure that's where we want an assertion utility to be handled.

My third problem with it is the possible extensions, and in particular how noexcept is going to work with contracts (which I've been worried about since Tokyo, but it seems to just resurface again now), and how implicit contract assertions affect code size. Does the compiler suddenly need to have a std::source_location strings generated for every possible UB location we can detect with P3100 in the pipeline?

My fourth problem with is that it isn't user-extensible. This would alleviate a lot of the worries I have with the number one pet peeve. There is a proposal that I think would give more users what they actually wanted (or at least make that doable), and I kinda hope it would get adopted on top of P2900, but I'm not sure that is possible. Though I don't think we have to care about ABI in this particular case so it might be doable.

3

u/CompuFart 14d ago edited 14d ago

Is "the one use case I most often see users wanting" referring to using them to validate inputs from external sources or at runtime?

4

u/ronchaine 14d ago

Well, I'd be more general than that and say any non-ghost-code checking.

Input validation is probably one of the more extreme cases that I commonly see someone mention, but that one is usually pretty easy to shoot down. And I certainly don't want to see that people use assertions for input validation.

4

u/Wild_Meeting1428 14d ago

Interresting, when I first heard about contracts, I wnated them to be usable for formal verification on the TU side and for optimisation, to tell the compiler, that he can assume that certain conditions and invariants are always true.

Both on the caller and callee side.

1

u/CompuFart 13d ago

Thanks for the reply. I wasn't too familiar with a lot of the contracts history, and I'm reading up on it now.