I'm not sure what you mean by endorses here and how this does or doesn't
apply to the fast-math example. Or to the case of using different
optimizations for different TUs. These latter examples are both allowed and
so are they not similarly 'endorsed'?



On Mon, 20 Oct 2025 at 21:57, John Spicer <jhs_at_[hidden]> wrote:

> I explicitly addressed your concern in my reply.
>
>
> If you use compiler options that explicitly change the meaning of code,
>> then you should know what they do.
>>
>> With contracts, you use facilities that the standard endorses and says
>> should work fine, but you get surprising results.
>>
>
> John.
>
>
> On Oct 20, 2025, at 4:09 PM, Oliver Rosten <oliver.rosten_at_[hidden]>
> wrote:
>
> I’m sorry too, because it doesn’t seem that complex.
>
>
> Well then I can only thank you for bearing with me.
>
> I wrote this above:
>
>> 1. The situation in which non-inlined inline functions end up with
>> different semantics is not ideal.
>> 2. This is a manifestation of a pre-existing problem in C++
>
>
> To which your response was:
>
> No, it is not a pre-existing problem.
>
>
> I’ve given an example which I think shows that this is a pre-existing
> problem. But I can’t see anywhere where you have acknowledged this.
>
> As I've been at pains to say, even if you are incorrect about this not
> being a pre-existing problem, I can nevertheless see why it still
> concerns you. But it seems worthwhile to attempt to establish some ground
> truths.
>
> O.
>
> On Mon, 20 Oct 2025 at 20:56, John Spicer <jhs_at_[hidden]> wrote:
>
>> I’m sorry too, because it doesn’t seem that complex.
>>
>> If you use compiler options that explicitly change the meaning of code,
>> then you should know what they do.
>>
>> With contracts, you use facilities that the standard endorses and says
>> should work fine, but you get surprising results.
>>
>> I would suggest you go back to P3835 and read it more closely.
>>
>> John.
>>
>> On Oct 20, 2025, at 3:11 PM, Oliver Rosten via SG21 <
>> sg21_at_[hidden]> wrote:
>>
>> Hi John,
>>
>> Sorry, but I'm still struggling to understand what you're trying convey.
>>
>> As I understand it, the rule that means the fast-math example above is
>> not an ODR violation is the same as the rule that means Contracts
>> mixed-mode is not an ODR violation. So I don't see what Contracts brings to
>> the table that's novel, in this context.
>>
>> What one could argue is new is that Contracts provides an additional way
>> for token-identical code to be compiled differently in different TUs.
>>
>> Is that what you're getting at?
>>
>> O.
>>
>> On Mon, 20 Oct 2025 at 18:26, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>>
>>> The onus of the specification (the actual normative requirements) to
>>> reflect "intent" should be on the author of said intent -- irrespective of
>>> the number of discussions that had been had on the topic. Not the other
>>> way around.
>>>
>>> -- Gaby
>>>
>>> -----Original Message-----
>>> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann
>>> via SG15
>>> Sent: Monday, October 20, 2025 9:58 AM
>>> To: sg15_at_[hidden]
>>> Cc: Tom Honermann <tom_at_[hidden]>; Ažman Gašper <
>>> gasper.azman_at_[hidden]>; sg21_at_[hidden]; Joshua Berne <
>>> berne_at_[hidden]>; Oliver Rosten <oliver.rosten_at_[hidden]>;
>>> sg15_at_[hidden]
>>> Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract
>>> checking for different libraries
>>>
>>>
>>> > 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.
>>> _______________________________________________
>>> SG15 mailing list
>>> SG15_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11504.php
>>
>>
>>
>