C++ Logo

sg15

Advanced search

Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract checking for different libraries

From: Ryan McDougall <mcdougall.ryan_at_[hidden]>
Date: Tue, 14 Oct 2025 09:46:57 -0700
Saying P2900 removes UB but... makes it slightly harder for some diagnoses
of that UB -- which is IFNDR anyway -- and is therefore "less safe -- full
stop!" is... not professionally sound -- to say the least. This
mountain/mole-hill/baby/bathwater territory.

We want C++ to continue to be used in cars and airplanes and medical
robots, when it's competing against other languages right? Yet as a
committee are trying to punt the only tool for expressing contracts in C++
because building libraries has always been slightly error prone? This is
not a good look for us to say the least -- and rest assured people not on
this list are watching.

On Tue, Oct 14, 2025 at 7:49 AM Ville Voutilainen via SG21 <
sg21_at_[hidden]> wrote:

> On Tue, 14 Oct 2025 at 13:21, John Spicer via SG15
> <sg15_at_[hidden]> wrote:
> >
> > You say "even if P2900 does not fix linking issues that are not inherent
> to Contracts”, but the point of P3835 is that the issues *are* inherent to
> contracts.
> >
> > The reason for this is that if you currently use a macro like
> MY_LIB_ASSERT(x), then you have control over what it does, even when your
> header is used by someone else. If you fail to get this right, it is an ODR
> violation. So you have done something that makes your program ill-formed,
> and your tools might be able to detect this.
> >
> > But if you use contracts, it is not an ODR violation, even when the
> functions end up doing different things.
>
> Right. P3846 says "This approach enables the use of ODR checkers". But
> it doesn't. It disables such checkers. Implementations
> can't reject mixed mode builds, even if they think there's some
> combination of chosen semantics that's undesirable.
>
> > So, contracts introduce a new problem that other mechanisms, including C
> assert, do not have.
>
> ..and, while claiming to solve ODR-related problems, the result is
> that all the practical problematic consequences of
> such ODR-related problems remain, but certain implementation
> techniques that work for solving them are now not allowed.
>
> In its description of various implementation strategies for mixed-mode
> builds, P2900 says
> "All these options are, of course, vastly better than making any
> program with mixed configurations
> IFNDR. "
>
> I do not know where that "of course" comes from, because that claim
> doesn't seem to be entirely correct.
> _______________________________________________
> 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/11248.php
>

Received on 2025-10-14 16:47:14