> there are existing and widely-employed deployment scenarios where
application programmers use binary libraries and do not compile all their
code.

And in these scenarios application programmers coordinate which versions of
the binaries they link with. If they're surprised they didn't read the
documentation.

We can excuse new learners and internet tinkerers for getting their clothes
caught on the sharp edges, but that is nothing new to C++ -- and that's not
the core audience for contracts.

Again it's regrettable that every new C++ feature causes complexity to
increase, but the mere existence of sharp edges has not stopped other good
and needed proposals.

> while it may be feasible for a hardened library implementation to make
different contract evaluation semantics ABI-incompatible

Contracts are designed to be used in *hardened libraries*. If you want to
make a toy project that is also incidentally binary only you're welcome to
-- just make sure you document exactly what you're trying to achieve and
why. You'll have to *ship multiple binaries* for the levels you intend to
support.

It's always been easily to abuse an ABI -- when has the committee decided
we need to prevent ABI abuse? That's a library implementor problem. We
technically don't even support ABI compatibility!

> It is highly non-obvious to me what actual benefits we gain from having
multiple inline function definitions in the same program

*No one* is shipping hardened inline contract-enabled functions.

*No one* is building mixed-mode hardened applications from header-only
contract-enabled libraries.

When building a *hardened library* you tell the user how it should be used,
and they use it the way you tell them, because they are building a *hardened
application*. For those who are not interested in hardening, you tell them
to either *turn them all off or all on*.

We have been building "modal" checking libraries for a very long time. No
one turns NDEBUG on or off haphazardly.

These are *problems on paper* that don't exist outside the committee. If
you want hardening, you follow the hardening rules. If you don't, then you
basically don't care about contracts.


On Tue, Oct 14, 2025 at 10:18 AM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Tue, 14 Oct 2025 at 19:30, Ryan McDougall via SG21
> <sg21_at_[hidden]> wrote:
> > I think what you're imagining is an internet-like ecosystem where small
> time developers and small time users are throwing things together without
> much training, documentation, or coordination.
>
> I don't think we are. There is no lack of training, documentation, or
> coordination, but there are existing and widely-employed deployment
> scenarios where application programmers
> use binary libraries and do not compile all their code. Quite a lot of
> such scenarios, in fact.
>
> >Contracts may offer a new facet, but the fundamental problem of sharing
> binaries is older than assert. It's just regular old 1970's library design:
> you have to produce multiple binaries for each target, be thoughtful about
> the ABI, and document how to use the ABI as intended.
>
> Being thoughtful about the ABI doesn't seem to help much, considering
> that while it may be feasible for a hardened standard library
> implementation
> to make different contract evaluation semantics ABI-incompatible, it
> may well be less so feasible for other libraries and applications
> combined
> with such libraries.
>
> > While some ODR violations are detectable, ODR is actually IFNDR -- so I
> don't think ODR is actually a preferable situation.
>
> It is highly non-obvious to me what actual benefits we gain from
> having multiple inline function definitions in the same program
> compiled with different contract evaluation semantics, and what actual
> practical problems we think we solve by making such
> multiple definitions ODR-equivalent.
>