On Mon, 20 Oct 2025 at 15:31, Timur Doumler <cpp_at_[hidden]> wrote:
>
>
>
> > On 20 Oct 2025, at 13:53, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Mon, 20 Oct 2025 at 14:36, Timur Doumler <cpp_at_[hidden]> wrote:
> >>
> >> That is not really an option 4, but rather a completely different feature, precisely because it loses the ability to change the semantic at build time. So really your option 4 is the same as my option 3: not standardise a feature that lets you change the semantic at build time.
> >
> > It doesn't lose the ability you speak of, and is nothing at all like
> > your option 3, because when supplied alongside P2900, it easily
> > attenuates if not completely alleviates the concerns about plain
> > P2900.
>
> I don't understand this. How can a specification simultaneously provide and not provide the ability to enable/disable a check via a build
> flag?

In other words, how can a programming language have both conditions and loops?

By providing two related but different facilities?

I quite fail to see how you come to the conclusion that if the
specification provides assertions that have a locked-in evaluation
semantic,
it then can't provide assertions that are controlled by build flags.
It can provide both.

Especially considering that I was under the impression that you have
read P3400, which, among other things, would also provide that
capability. With it, you can do
what I describe, by defining a label that completely ignores build
flags, and decides the properties of the contract it's associated
with via some other means. And then you can provide other labels that
do partially or fully take build flags into account. And then
you can still use contracts that do not have associated labels.

I find the question astonishing.