Sorry, this is a weakness of the medium -- what I'm saying is "no one is
producing inline functions that are promised to be hardened in a legally
binding way, such as in safety critical applications" -- precisely because
putting hardening in source that is copy-pasta into a TU weakens the
promise. It's the legally binding promise of hardening that's at stake. If
your user is determined to defeat your library-level hardening, you cannot
control that. Fighting your users is a battle that can't be won. You give
them library hardening, and they either enable it or they don't.

What I'm saying is that hardened library writers do not rely on inlining.
The standard library occupies a bit of a unique space since it has (to try)
to be all things to all people -- including the people who cannot imagine a
reason why hardening should be turned off. Even if P2900 is somehow
universally declared unsuitable for the standard library, this has no
bearing on whether P2900 is necessary for Functional Safety. Neither the
standard library nor GSL are the only or primary users of contracts.

Now I've already said enough on the matter, and for the sake of our readers
I'm going to step away from the discussion for a while.

Cheers,

On Tue, Oct 14, 2025 at 11:08 AM Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> [Ryan]
>
> - *No one* is shipping hardened inline contract-enabled functions.
>
>
>
> I don’t know what you mean by this. Is that because contracts don’t exist
> in C++? Something else?
>
>
>
> Organizations routinely ship running products (not debug, actual retail),
> with this https://github.com/microsoft/GSL , unsuppressed checking on;
> e.g. on gsl::span<T>::operator[]
> <https://github.com/microsoft/GSL/blob/main/include/gsl/span#L648>. You
> can see more in that file. The hardened standard library reflects parts of
> that. This isn’t debug exercise.
>
>
>
> -- Gaby
>
>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Ryan
> McDougall via SG15
> *Sent:* Tuesday, October 14, 2025 1:53 PM
> *To:* Ville Voutilainen <ville.voutilainen_at_[hidden]>
> *Cc:* Ryan McDougall <mcdougall.ryan_at_[hidden]>; sg21_at_[hidden];
> John Spicer <jhs_at_[hidden]>; sg15_at_[hidden]
> *Subject:* Re: [isocpp-sg15] [isocpp-sg21] P3835 -- Different contract
> checking for different libraries
>
>
>
> > 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.
>
>