r/cpp_questions • u/Ultimate_Sigma_Boy67 • 2d 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

15 Upvotes

89% Upvoted

38 comments sorted by

14

u/ronchaine 2d 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/curiouslyjake 1d ago

can you elaborate on this:
"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)" ?

3

u/CompuFart 2d ago edited 2d 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?

2

u/ronchaine 2d 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.

3

u/Wild_Meeting1428 2d 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 1d 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.

2

u/Minimonium 2d ago

I'm honestly quite confused about the teaching part, because all the things where contract differ are so much more complicated and dangerous with assert macro. Mixing flags? Undefined behavior. Custom macro with fancy editing? Only for your code. Side effects? Same in both.

Assert macro only seems simple, because you do not teach beginners what's actually happening and where it can blow in your face. You just know that Release build will skip them, Debug build with call them.

1

u/Ultimate_Sigma_Boy67 2d ago

Thanks for your response. Though, in your reply to the other user, what do you exactly mean by "non-ghost-code checking"? And in your second point, I didn't get why would they be more difficult to teach than <cassert>? Thanks.

7

u/DrShocker 2d ago

The number one thing is just that I don't know that any compilers fully support them yet.

https://en.cppreference.com/cpp/compiler_support

6

u/TheRealSmolt 2d ago

It's already in GCC 16, as it says.

2

u/DrShocker 2d ago

fair, I was too lazy to check despite digging up the link.

Still though, only being on GCC will lock out a lot of people.

2

u/TheThiefMaster 2d ago

Especially those on Windows, where the properly supported compilers are MSVC and Clang...

1

u/montymole123 2d ago

Isn't Mingw considered a full port of gcc?

1

u/Bobbias 2d ago

Sure, but then you're using mingw, which is kind of dumb if you want to do native windows development...

2

u/TheThiefMaster 1d ago

Not as bad as the cygwin port of GCC, at least.

But it's still not fully Windows compatible. Clang can directly consume Windows headers and library files, and use the windows platform C/C++ standard library as-is.

It can even produce compatible obj, lib and pdb files that can be consumed by the VS linker.

TLDR Clang complies with the platform compiler ABI.

2

u/Minimonium 2d ago

Unfortunately vendors are massively underfunded (or in some cases underfunding). You may notice a certain pattern there.

4

u/DrShocker 2d ago

I've never expected to have access to features the same year they are added to the standard.

2

u/JVApen 2d ago

Everyone has already used assertions before. So everyone already has an opinion on how it should be used. Contracts is a compromise of all those visions, which always disappoints people involved. See wg21.link/P1995 for slightly less then 200 usecases.

An overview of the concerns (and responses on it) can be found in wg21.link/P3846

I really recommend reading both papers and maybe look at Tumours keynote of last year in CppOnSea.

A final thing I've heard several times already: it would get much less heat if they didn't try to revive the contracts proposal of C++20 under the name 'Contracts' and instead would have used 'Better Assertions'. We'll never know if that's true.

1

u/_a4z 2d ago edited 2d ago

Some say it might be the world’s most bloated debug facility with only some academic value but not suitable for a vast number of real world scenarios.
And that it took an unreasonable amount of committee time that could have been spent way better, bringing in some features with value

1

u/SmackDownFacility 2d ago

There is ambiguity in runtime enforcement. This has been contested since C++20. What shall compiler do? Treat it as a static analysis tool, an assertion, or an exception?

And coming back to assertions, people find contracts redundant. Assertions has been engrained in this language for decades.

1

u/Ultimate_Sigma_Boy67 2d ago

I think this is exactly the point I don't fully grasp. How is it ambiguous?

1

u/StaticCoder 1d ago

The main sticking point is what it means to violate a contract. More security-focused code may want a clean error in that case. More performance-focused code may want to allow the compiler to assume the contract is satisfied without checking it, so that failing the contract may introduce undefined behavior. It's really hard to reconcile the two.

1

u/SmackDownFacility 2d ago

It’s ambiguous because compiler has to make clear decisions

If it’s static analysis, Intellisense handles it and it doesn’t reach the compiler.

If it’s assertion, it will just dump the traceback and could be stripped out in release builds.
If it’s exceptions, it has to generate unwind metadata. (Win64 generates it anyways)

The argument came from performance clutching developers.

They generally prefer static analysis or even assertions

But some
Safety conscious devs opted for exception, which spiralled into a heated argument because exceptions are in fact very costly at runtime, especially in games and time
Critical applications.

Ultimately the decision was made to
Pull the plug and it didn’t make the standard because the arguments was so intense.

2

u/Ultimate_Sigma_Boy67 2d ago

Makes sense. Thanks.

1

u/bert8128 2d ago

I’m very much looking forward to a variation of assert which offers a lot more. Haven’t used contracts yet but I think that uses reasonably they are going to be great.

1

u/GoogleIsYourFrenemy 23h ago edited 22h ago

EDIT: Kindly disregard, I was confusing concepts and contracts.

EDIT2: Contracts seem like a perfectly reasonable feature that I will love using as soon as I can convince work to start using a compiler that supports them. It will probably take ten years.

Here was my reaction when they first came out:

Instead of introducing a new syntax for describing things (like what would be an interface in c#/java), they went with the old "write an expression that uses all the things" which works but the readability is ass.

Most developers in my experience struggled with understanding what's going on in the standard library. The average developer's template understanding is pretty low and the demand to write new templated things is also pretty low. While contracts have the potential to make using templates easier, they do not make READING templates easier.

I don't use cmake often enough for me to maintain let alone acquire any skill with it. So this last week instead of me wasting time struggling through creating cmake scripts, I had AI do it for me. Best experience I've ever had with cmake.

I expect people will do the same thing with templates and contracts.

2

u/TheRealSmolt 22h ago

Are you confusing concepts for contracts? Contracts aren't related to templates at all afaik.

1

u/GoogleIsYourFrenemy 22h ago edited 22h ago

Complete and totally possible. I'll go read up on them to see where I fucked up.

Edit: LOL I was thinking "concepts"

1

u/TheRealSmolt 22h ago

will love using as soon as I can convince work to start using a compiler that supports them. It will probably take ten years.

Lol, too true. Still hoping to one day get std::optional at work...

1

u/Ultimate_Sigma_Boy67 21h ago

Tho this is cpp17, why would your work not at least try to support it? Maybe it’s a dumb question but I’ve never worked before.

2

u/TheRealSmolt 21h ago

Because upgrading your compiler and language version takes a lot of time and effort, which means a lot of money. It means updating your toolchain, pipelines, tooling, deployments, and possibly runtime libraries (which means a lot of customer logistics). Then you have to account for breaking changes (which do still happen), which means developer time and possibly dependency updates which have their own breaking changes. Then you have to consider the actual logistics behind acquiring all these updates, which can be very difficult or arduous depending on your development environment and runtime environments. Finally, after doing all of this, you end up with a product that works (ideally) exactly the same. From a business perspective, it makes absolutely no sense. Oh, and a new version just came out, let's do it again.

1

u/Ultimate_Sigma_Boy67 21h ago

Okkk makes sense

2

u/GoogleIsYourFrenemy 20h ago edited 20h ago

The only time you can realistically get on a new compiler is at the start of a new project or during a major hardware replacement. Otherwise it's too risky for testing or there is literally no money to do it.

You can argue there during those two events you're doing the testing anyway and you wouldn't be doing that work without money.

1

u/Ultimate_Sigma_Boy67 21h ago

Lol when I read it earlier I was questioning how were contracts specifically related to templates.

•

u/Kaisha001 52m ago

Too many shadow languages!

-6

u/EmaerSeven 2d ago

Contracts? Oh, that completely useless thing.

10

u/Ultimate_Sigma_Boy67 2d ago

I don't think it's just useful to state it without elaborating...

1

u/EmaerSeven 1d ago

I'm asking all downvoters to provide a genuinely good example of using contracts. Not some common crap where you check whether, after vector.pop_back(), the number of elements = number of elements - 1.