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
>