On Mon, 20 Oct 2025 at 19:09, Joshua Berne <berne@notadragon.com> wrote:
>
>
>
> On Mon, Oct 20, 2025 at 12:01 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>
>> The contracts specification specifies them to be compatible.
>
>
> Where?
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?
multiple TUs in general can have whichever contract-evaluation
semantics chosen by whichever implementation-defined
mechanism, but that mechanism must select one of the standardized
semantics.
Where does anything in the specification say that there is a contract-evaluation semantic chosen for a TU?
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. Rules about things we don't define seem like they would be a bigger problem.
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.
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.
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.
I've now gone on with details and technical answers and the hopes of clarifying things. Let me try one last time in a more succinct fashion
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.