And those that don't have their use case satisfied can't rely on
workarounds, same as they undoubtedly have been doing for years, and wait 3
more years until we have a more complete contracts feature? Is there
anything in the current MVP closing the door on this eventuality?

On Mon, Oct 27, 2025 at 2:33 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> 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. "
>