On Thu, Oct 23, 2025 at 10:31 PM John Spicer via SG15 <sg15_at_[hidden]>
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_[hidden]> 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.