On 10/27/25 00:23, Herb Sutter wrote:
> Axiom: A fundamental property of contracts is that they are
redundant – they never change the meaning of code.
Contracts already change the meaning of code, in case of out of contract
calls. In enforce they do not continue and in ignore they continue as
fully correct code.
This is a significant difference in behavior, useful to know for
programmers. Yet not visible in the code.

> So in the above example, I would expect:
>
>
>
> (1) A tool that analyzes the function body would _always_ issue a
“does not return on all paths” warning (and all compilers do:
https://godbolt.org/z/TebeM1cdc). To silence the warning, add “else
std::abort()” “else throw something{};” or or similar. This is right,
because the function can indeed be called out of contract, and if so
cannot just fall off the end.
the purpose of "always" is that a functions can not be entered out of
contracts, so analyzers should not assume they will.
>
> (2) A (possibly different) tool that also analyzes contracts would
_additionally_ issue a warning if it discovers code paths that would
violate the precondition. Contract-related warnings are purely in
addition to, not instead of and not interacting with, other warnings.

What are a user supposed to do with contradictory warnings? It's going
to be hard on projects with warnings-as-errors.

We do want to remove redundant code. One of the "safety" features
contracts bring is the ability to write simple code, excluding
irrelevant parts. Simple code has fewer bugs.

If we do no clearly separate guaranteed "always" contracts from
sometimes checked "maybe" contracts many programmers will consider any
contracts a promise and skip branches or defenses.
It is not uncommon to see assert used in this way.

But trusting maybe contracts and then build with ignore is really
indifferent from assume semantics.
Not by the optimizer, but just programmers optimizing by hand.
I know many people here has issues with assume semantics. They should
think again about this.
And while I have nothing against assume semantics per se I really don't
want to see it sneak into applications under the pretense of ignore like
this.