Date: Mon, 27 Oct 2025 14:33:20 +0200
On Mon, 27 Oct 2025 at 14:20, Andrei Zissu <andrziss_at_[hidden]> wrote:
>
> I'm not sure if these are the right questions or not, but it seems to me the main question discussed here so far, namely how are contract violations handled, is the wrong one. You shouldn't rely on contracts to protect you from UB (and any other undesired behavior) but rather use them to detect such behavior. Static checkers should come in to make sure there is no additional invalid behavior not detected by those contracts, and to make sure assuming those contracts will hold is safe. Lacking such certainty you should rely on traditional flow control for handling invalid use cases.
Well, it's easy to find people to whom it's not about how the
violations are handled. The main aspect of it to them is a guarantee
that execution Will Not Continue into the code that follows. For some,
it's important that that guarantee is there and as little other
code as possible is executed. For some others, that's completely
secondary, and they can tolerate a diagnostic print or the absense
of it, but they also want the Will Not Continue part. There are yet
others who are happy with an exception instead of termination,
but to them as well the Will Not Continue part is of utmost
importance. And it's indeed Will Not Continue Into The Code That
Follows,
it's not "must abort the program".
The "use traditional flow control" doesn't cover the desire to be able
to have that guarantee at a function declaration level,
as a guarantee that the function definition cannot fail to deliver and
cannot forget to deliver.
So.. "you shouldn't rely on contracts for this" is an intriguing piece
of advice, but it seems to be rejected as such, with
"but I want contracts like that, I want contracts that are enforced,
and guaranteed to be enforced".
And that's not a new idea when discussing contracts in C++. You can find it in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r3.html
if you search for "always". A highly significant bit is in "2.10
Invoking the handler":
"The proposal does not support the direct invocation of the violation
handler. Allowing so, would imply access to handler supplied by the
user, and could result into a security issue. Instead, we have added
an additional assertion-level named always. Such assertion cannot be
disbled<sic> and the check is performed even when the program is built
with build-level set to off. "
>
> I'm not sure if these are the right questions or not, but it seems to me the main question discussed here so far, namely how are contract violations handled, is the wrong one. You shouldn't rely on contracts to protect you from UB (and any other undesired behavior) but rather use them to detect such behavior. Static checkers should come in to make sure there is no additional invalid behavior not detected by those contracts, and to make sure assuming those contracts will hold is safe. Lacking such certainty you should rely on traditional flow control for handling invalid use cases.
Well, it's easy to find people to whom it's not about how the
violations are handled. The main aspect of it to them is a guarantee
that execution Will Not Continue into the code that follows. For some,
it's important that that guarantee is there and as little other
code as possible is executed. For some others, that's completely
secondary, and they can tolerate a diagnostic print or the absense
of it, but they also want the Will Not Continue part. There are yet
others who are happy with an exception instead of termination,
but to them as well the Will Not Continue part is of utmost
importance. And it's indeed Will Not Continue Into The Code That
Follows,
it's not "must abort the program".
The "use traditional flow control" doesn't cover the desire to be able
to have that guarantee at a function declaration level,
as a guarantee that the function definition cannot fail to deliver and
cannot forget to deliver.
So.. "you shouldn't rely on contracts for this" is an intriguing piece
of advice, but it seems to be rejected as such, with
"but I want contracts like that, I want contracts that are enforced,
and guaranteed to be enforced".
And that's not a new idea when discussing contracts in C++. You can find it in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r3.html
if you search for "always". A highly significant bit is in "2.10
Invoking the handler":
"The proposal does not support the direct invocation of the violation
handler. Allowing so, would imply access to handler supplied by the
user, and could result into a security issue. Instead, we have added
an additional assertion-level named always. Such assertion cannot be
disbled<sic> and the check is performed even when the program is built
with build-level set to off. "
Received on 2025-10-27 12:33:35