> On Oct 20, 2025, at 11:31 AM, Ville Voutilainen via SG15 <sg15_at_[hidden]> wrote:
>
> On Mon, 20 Oct 2025 at 19:24, Joshua Berne <berne_at_[hidden]> wrote:
>>> Everywhere. Multiple definitions of inline functions with different
>>> contract evaluation semantics are ODR-equivalent,
>> Where does the specification say that the definition of a contract assertion has a contract evaluation semantic?
>
> What part in what I wrote uttered the words "definition of a contract
> assertion"?
>
>>> And none of that is said to be in any way
>>> incompatible anywhere.
>> You seem to be claiming that things that aren't defined are not being described as incompatible and that's a problem.
>
> The different evaluation semantics are defined, and nothing says they
> are some incompatible parameters of the abstract machine.
>
>>> You can even have different evaluation
>>> semantics for different calls of the same function, defined
>>> just once, including defined in the same TU, and nowhere in the
>>> standard does anything say that any of that is incompatible
>>> in any way.
>> Yes, with full flexibility to the implementation to define how and when that happens.
>
> Yes, how and when that selection of a semantic happens, but not that
> the result is ill-formed.
>
>> Implementations are also, because they are defining this, perfectly able to say when the choices that dictate the evaluation semantics are or are not compatible with one another.
>
> They define the mechanism for that selection, but not the
> well-formedness of the result.
>
>> Our specification is entirely about allowing the possibility of mixed modes being supported by a compiler, but that same allowance also gives platforms complete freedom to *not* support mixed modes of any sort. "Full stop" as you might say.
>
> It doesn't. It gives implementations freedom to not provide certain
> selections, but it doesn't give them freedom to say that
> using ignore here and enforce there isn't well-formed. And
> implementations can't support just one evaluation semantic
> everywhere, due to practical reasons.
>
> Your specification may be entirely about whatever fluffy bunnies you
> wish, but it doesn't say what you're suggesting it says.
>
>>> Everywhere.
>> Since you've failed to provide an actual citation for a rule in the wording itself, thank you for clarifying that this is not actually a rule in the specification of C++26 contracts.
>
> I already gave you that rule. It's [intro.compliance.general]/2.1, and
> lack of any rules being violated.

I’m confident that, given the many discussions we’ve had on this topic, you understand the P2900 intent to be what Joshua stated. If not, perhaps you can accept the intent to be what Joshua stated given that he is one of the primary authors and his view is supported by many coauthors, including myself.

Perhaps you could propose a wording change that you believe would make the standard better reflect that intent. That would be a productive outcome of this discussion.

Tom.