Date: Mon, 20 Oct 2025 19:31:33 +0300
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.
>> 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.
Received on 2025-10-20 16:31:47