>
> 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
>
>
>