> If you want to provide binary dependencies, does that mean you need to
have each build in 4 variations, per contract variations.

After reading p3835 and p3829, I believe there's a fundamental
misconception about compatibility guarantees when mixing compilation flags
across TUs.

I'll state that the MVP Contracts are required for adoption in the Standard
to approach the issue of soundness of mixed mode environments.

Let's look at ASSERTs as an established industry practice which shares most
of the limitations with Contracts.

It's not controversial to say that ASSERTs are used widely, with Release
builds commonly disabling ASSERTs and Debug builds commonly enabling them.
The need to be able to disable ASSERTs is also fairly established, with
industries such as Game Development going as far as to disable ASSERTs and
similar instrumentation mechanisms even in Debug builds for the needs of
performance. The platform requires you to use the same macro for every
affected TU in the build however.

On the other hand, there exists at least one widely used platform on which
users are used to recklessly mix Debug and Release versions in the same
build.

Mixing such builds is an ODR violation from the language side. From the
point of linkers lies a soundness problem. We can borrow p3829's
misattributed example of an IPO based on ASSERT invocation, which leads to
programs which produce incorrect results with correct inputs. Because of
the mixed Release/Debug mode.

The problem is fundamental to the use of simple linkers in the C++
toolchain. Neither scope-local mode attributes, nor strong types can help
the problem given scenarios discussed in these papers. If a third-party
dependency explicitly would disable Contracts in a hostile manner, it would
disable ASSERTs-like mechanisms as well, driven by the same motivations,
leading to more severe problems because of the unsoundness.

Now, the Contract MVP does the ODR relaxation, where compilers are not
allowed to optimize around the invocation of contract_assert statements.
Meaning even if code ends up in a mixed mode environment - the correct
inputs would produce correct outputs.

To answer your question, relying on the industry practice - platforms will
adopt a specific Contract mode for Release and Debug builds, similar to
ASSERTs. Since each platform/distribution adopts its own default toolchain
- I don't expect the number of builds we do today to differ from what we
will need with Contracts. But unlike ASSERTs, Contracts are sound.


On Wed, Sep 24, 2025 at 4:06 PM Harald Achitz via SG15 <
sg15_at_[hidden]> wrote:

> On 2025-09-24 15:36, René Ferdinand Rivera Morell wrote:
>
> On Wed, Sep 24, 2025 at 6:10 AM Harald Achitz via Admin <
> admin_at_[hidden]> wrote:
>
>> The Swedish SC22 mirror committee TK611/AG09 has discussed the current
>> working draft of C++26 and identified concerns regarding contract
>> assertions. We have summarized these in the attached document.
>>
>> As convener, I see it as my duty to mediate these concerns. I would
>> therefore appreciate guidance on how to proceed and to ensure that our
>> experts’ concerns, as well as similar concerns from others, are taken
>> into account.
>>
>
> From the comments:
>
> Contracts introduce several new build configurations. The impact on the
> build system and binary
> dependency management has not received sufficient focus.
>
>
> FYI..
>
> <https://github.com/cplusplus/papers/issues/1923#issuecomment-2198207843>
> <https://github.com/cplusplus/papers/issues/1589#issuecomment-1804470319>
>
> I personally don't remember any concerns by build and packaging ecosystem
> experts on this subject when it's been discussed. Contracts mirror existing
> practice for binary linking and is easily managed with existing build
> systems and package managers.
>
>
> --
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supongas Nada
> -- Robot Dreams - http://robot-dreams.net
>
> Thanks for the reply. Rene
>
> Having some interest on the build issue myself, I would be thankful to
> learn about the following topics:
>
> Will it be easily manageable to tell the linker: hey, give me libfoo with
> contract assertions enabled, and that is using this special contract
> handler? And get an error if libfoo in that flavor is not available, but
> only in others other configuration.
> or is it only easily manageable when you build the whole source tree
> including dependencies with profiles / tripplets, or what ever your control
> file is.
>
> If you want to provide binary dependencies, does that mean you need to
> have each build in 4 variations, per contract variations.
>
> And is it even possible to have different contract handlers set, in
> dependencies, or do people make that up?
>
> What will, for example, Linux distributions add to their build, will it be
> implementation defined? And I can tell from the binary in the system what
> it is.
>
> If such questions have been discussed, is there some documentation to read
> up on the outcome?
>
> /Harald
>
>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>