Date: Tue, 21 Oct 2025 10:27:45 +0300
On Tue, 21 Oct 2025 at 09:07, Timur Doumler <cpp_at_[hidden]> wrote:
> Specifically to this point, since you brought it up repeatedly:
>
> > On 20 Oct 2025, at 15:32, Ville Voutilainen via SG15 <sg15_at_[hidden]> wrote:
> > 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.
>
> It appears that the phrasing of this sentence in P3846 is not very clear and it is easy to misunderstand it. Can you help me phrase it more clearly? The intent was to say that if you want to use P2900 contract assertions instead of your existing assertion macros, and you are OK with the mixed-mode behaviour of P2900 (because that's how all existing assertion macros already work today!) and now you want to use ODR checkers to find *other* ODR violations in your program (unrelated to contract assertions), then having assertions where mixed-mode is an ODR violation makes that impossible because the ODR checker will fire at those assertions. However, if P2900 now makes the already existing mixed-mode behaviour *not* an ODR violation, then you can actually use the ODR checker to find other ODR violations which tend to have much more dire consequences (thus you get a net benefit as you find even more bugs). Remember that the *worst* case that can occur with P2900 mixed-mode is that an assertion you intended to be checked in TU1 but has been compiled with "ignore" in TU2 will also be ignored in TU1, which won't have an impact on correct code outside of those assertions, whereas other ODR violations can break *correct* code in unpredictable and hard-to-debug ways (for example, an ODR violation due to class layout mismatches across TUs — I suspect many of us had to debug those at some point in our careers) so you probably do want to be able to use tooling to find those other ODR violations. That's the net benefit that's being advertised here. Apologies if this wasn't clear and I would appreciate suggestions for how to phrase it better.
Well, here's an easy improvement:
<del>This approach enables the use of ODR checkers and makes unsound
optimisations that would otherwise break
the program non-conforming.</del>
Perhaps a more elaborate one would be along the lines of
This approach <del>enables the use of</del><ins>is intended to
help</ins> ODR checkers <ins>find other ODR violations, unrelated to
contract</ins> <del>and makes unsound optimisations that would
otherwise break the program non-conforming</del>.
After all, we seem to have converged on an agreement that
inter-procedural optimizations based on a locally visible definition
of an inline function
are unsound to begin with, so their conformance is.. ..perhaps not so relevant.
> Specifically to this point, since you brought it up repeatedly:
>
> > On 20 Oct 2025, at 15:32, Ville Voutilainen via SG15 <sg15_at_[hidden]> wrote:
> > 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.
>
> It appears that the phrasing of this sentence in P3846 is not very clear and it is easy to misunderstand it. Can you help me phrase it more clearly? The intent was to say that if you want to use P2900 contract assertions instead of your existing assertion macros, and you are OK with the mixed-mode behaviour of P2900 (because that's how all existing assertion macros already work today!) and now you want to use ODR checkers to find *other* ODR violations in your program (unrelated to contract assertions), then having assertions where mixed-mode is an ODR violation makes that impossible because the ODR checker will fire at those assertions. However, if P2900 now makes the already existing mixed-mode behaviour *not* an ODR violation, then you can actually use the ODR checker to find other ODR violations which tend to have much more dire consequences (thus you get a net benefit as you find even more bugs). Remember that the *worst* case that can occur with P2900 mixed-mode is that an assertion you intended to be checked in TU1 but has been compiled with "ignore" in TU2 will also be ignored in TU1, which won't have an impact on correct code outside of those assertions, whereas other ODR violations can break *correct* code in unpredictable and hard-to-debug ways (for example, an ODR violation due to class layout mismatches across TUs — I suspect many of us had to debug those at some point in our careers) so you probably do want to be able to use tooling to find those other ODR violations. That's the net benefit that's being advertised here. Apologies if this wasn't clear and I would appreciate suggestions for how to phrase it better.
Well, here's an easy improvement:
<del>This approach enables the use of ODR checkers and makes unsound
optimisations that would otherwise break
the program non-conforming.</del>
Perhaps a more elaborate one would be along the lines of
This approach <del>enables the use of</del><ins>is intended to
help</ins> ODR checkers <ins>find other ODR violations, unrelated to
contract</ins> <del>and makes unsound optimisations that would
otherwise break the program non-conforming</del>.
After all, we seem to have converged on an agreement that
inter-procedural optimizations based on a locally visible definition
of an inline function
are unsound to begin with, so their conformance is.. ..perhaps not so relevant.
Received on 2025-10-21 07:27:59