On 10/24/25 12:33, Peter Bindels wrote:
>
>
> On Thu, Oct 23, 2025 at 10:31 PM John Spicer via SG15
> <sg15_at_lists.isocpp.org> wrote:
>
> I want to provide the guarantee because I want to be able to have
> checks that I know are enforced.
>
> If I don’t know they are enforced, then I’ll keep using my
> macro-based solution where I know that they are.
>
> As an example, the EDG front end can be built as a library, and to
> use it, you need to include some EDG header files.
>
> I don’t want my checks to go away because the user of the library
> chose a different semantic.
>
> I hope that answers the question. If not, let me know.
>
>
> Combined with
>
> On Fri, Oct 24, 2025 at 11:12 AM Jonas Persson via SG21
> <sg21_at_lists.isocpp.org> wrote:
>
> Labels will not solve the full problem. It may give us the ability to
> force a runtime assertion in production, but it does not in practice
> clearly separate ignorable and non-ignorable checks.
> A label can turn contracts on and off based on any kinds of sources
> including build flags.
> Even with labels we must be able to mark the contracts as
> guaranteed or not.
> Where guaranteed means that it will only pass if its condition is
> true,
> not because any label property.
>
>
> I think the goal you're both trying to achieve can be summarized /
> written as
>
> As a library developer / owner
> I want to be 100% sure the contracts on my functions are evaluated in
> enforce mode
> So that when the user makes a mistake and/or files a bug report, I can
> be sure that the contracts were enforced, so the bug report will
> either say the contract was violated or there's an actual bug.
>
> Is that a fair way to summarize it? I'm not quite sure on the "so
> that" part.


Our goals are somewhat related, but for me it is not about requiring
runtime aborts or logs.
Mine is just that the contract can always be trusted. It cannot be
ignored or observed, since then there is a possibility that it continues
execution with incorrect values.