> You can't use them for safety checks, because you must assume they won't be run.

This is also true of assert, though. It can be compiled out so shouldn't be used for anything that must run.

Its pretty easy for me to guarantee that my asserts will all always be run via NDEBUG. I can't make that same guarantee for contracts

▲

Jtsummers 43 minutes ago | parent [-]

> Its pretty easy for me to guarantee that my asserts will all always be run via NDEBUG.

That's the opposite of what NDEBUG does. https://en.cppreference.com/cpp/error/assert

Critical bit:

> 1) If NDEBUG is defined as a macro name at the point in the source code where <cassert> or <assert.h> is included, the assertion is disabled: assert does nothing.

It also is impossible to guarantee it unless you're the only one compiling the program. If you've built a library that others can build and relied on asserts executing for your library to be correct, you wrote a bad library.

EDIT: Neither asserts nor these C++26 contract features should be used in a way that requires that they be executed. If you do, you're using them wrong because it is valid for someone to disable them as runtime checks. If the code must run, you should use some other mechanism, I'd recommend an if statement.

	▲	20k 6 minutes ago \| parent [-]
		Of course? You simply undefine NDEBUG in your library Its trivially easy to guarantee that an assert always runs, and its well defined behaviour according to the spec. There's no reason not to if you want to use asserts in a way that guarantees that they always fire, which is a supported use case. Its common practice There's no equivalent for contracts