On Tue, 14 Oct 2025 at 20:53, Ryan McDougall <mcdougall.ryan@gmail.com> 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.