Date: Mon, 27 Oct 2025 09:31:01 -0400
On Mon, Oct 27, 2025 at 2:33 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> 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. "
>
And to provide full context, in r4 of that same paper you'll find the
following description of why it was removed:
"Previous versions of this proposal included an always assertion level.
That level was introduced as a way to make it possible to invoke the
violation handler. However, the mechanism seemed to be problematic when
used in interfaces. Addtionally, it resulted to be more controversial and
not addressing exactly initial intent."
But I did learn something today that this was part of early versions of
P0542, but it's also clear that the consensus opinion of EWG has remained
consistently that this is not a necessary part of the feature set and at
times even one to which there has been strong opposition. At least some
of those involved in the first discussion had completely forgotten that
P0542R1 had even introduced the idea in the first place.
Since then of course we have had the functionality proposed ---
P1429/P1607 certainly satisfied this use case with explicit semantics, but
that was not motivated by the desire to have "always' but rather to provide
building blocks for users to build their own variations of flexible
semantics. P3400 satisfies the use case as a side effect of providing
flexibility in a similar fashion. We've also spent a lot of time in SG21
and EWG polling what features to target as part of the initial MVP and what
features should be left until later, and the Contracts feature in the
working draft today is the result of that decision making.
ville.voutilainen_at_[hidden]> wrote:
> 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. "
>
And to provide full context, in r4 of that same paper you'll find the
following description of why it was removed:
"Previous versions of this proposal included an always assertion level.
That level was introduced as a way to make it possible to invoke the
violation handler. However, the mechanism seemed to be problematic when
used in interfaces. Addtionally, it resulted to be more controversial and
not addressing exactly initial intent."
But I did learn something today that this was part of early versions of
P0542, but it's also clear that the consensus opinion of EWG has remained
consistently that this is not a necessary part of the feature set and at
times even one to which there has been strong opposition. At least some
of those involved in the first discussion had completely forgotten that
P0542R1 had even introduced the idea in the first place.
Since then of course we have had the functionality proposed ---
P1429/P1607 certainly satisfied this use case with explicit semantics, but
that was not motivated by the desire to have "always' but rather to provide
building blocks for users to build their own variations of flexible
semantics. P3400 satisfies the use case as a side effect of providing
flexibility in a similar fashion. We've also spent a lot of time in SG21
and EWG polling what features to target as part of the initial MVP and what
features should be left until later, and the Contracts feature in the
working draft today is the result of that decision making.
Received on 2025-10-27 13:31:17