On Mon, 20 Oct 2025 at 16:13, Daniela Engert via SG15
<sg15_at_[hidden]> wrote:
>
> I agree with the assessment, that mixing contract evaluation semantics introduces a problem where was none such before. While it isn't an (sometimes detectable) ODR violation in the token sense, it is one that is taking place at the very moment when the actual machine instructions are generated - and this is new.

Right. And the end result is that we get most, maybe all, of the
problems of ODR violations, and at the same time take away some of the
tools
implementation vendors have to deal with those problems.

That's not "Solving the ODR problem", like P3846 and various other
papers try to claim. It's not solving the problem at all, and it's
making it worse.
And in particular, P3846 has this gem in it:
"This approach enables the use of ODR checkers and makes unsound
optimisations that would otherwise break
the program non-conforming."

"This approach", meaning P2900, doesn't enable the use of ODR
checkers. It disables them.