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

> On Tue, 14 Oct 2025 at 20:53, Ryan McDougall <mcdougall.ryan_at_[hidden]>
> wrote:
> > Contracts are designed to be used in hardened libraries.
>
> They don't seem to succeed at what you're telling them to be designed
> for: https://isocpp.org/files/papers/D3878R0.html


I did not say that hardening is only for the standard library.

I'm not going to refute a new D-paper in real time, but I suspect that the
claim "C++26 standard library implementations cannot implement hardened
preconditions in terms of contracts" isn't wholly supported since other
standard library implementers patently disagree.

I think the next line is suggestive: "standard library hardening must be
allowed to be turned on regardless of what the evaluation semantics of
contracts in the rest of the program and even in the same TU are." -- this
is patently not true: if you want a hardened application you have to build
with hardening enabled -- problem solved. If you don't turn on hardening
you don't get a hardened application.

> > 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.
>
> In the sense that nobody is shipping contract-enabled anything, sure,
> but all our standard library implementations ship
> hardened inline functions.
>

In the sense that no one ships a -O2 optimized inline function: if it's
inlined into the TU, it gets the TU's optimization level. Inlining is a
linker directive, not a hardening or performance tool.

If it's inline in a header, you've given up control. Trying to claw that
back is foolish.


> > When building a hardened library you tell the user how it should be
> used, and they use it the way you tell them
>
> ..and it is used in a way that doesn't include flipping the hardening
> off by defining a contract evaluation semantic for your
> own code, or flipping it off by linking in some other TU.
>

What about flipping optimization on or off? The idea that you can make your
code "hard" and the user cannot undo that is foolish.

The user wants a fast program, and the user wants a memory safe program,
and wants a functionally safe program -- if they conspire to find a way to
defeat that, it's not the standard's problem.