pon., 29 wrz 2025 o 22:14 John Spicer via SG21 <sg21_at_[hidden]>
napisał(a):

> I think that compile-time and link-time selection of semantics is a
> desirable feature.
>
> But that misses the essential point of p3835r0 that the semantics need to
> apply to software “components” and not to translation units or to the
> entire program.
>
> If you consider the example in the paper I referenced, it is essential
> that the check in l1.cpp fail.
>
> There could be some other contract check in c1.cpp that is expected to be
> ignored.
>
> The key issue is not, IMO, how you control a “checking mode” that applies
> to a TU or the program, the issue is how you apply various “checking modes”
> to different components (e.g., libraries).
>
> There are a number of possible solutions to this problem, each of which
> have their own tradeoffs.
>
> But the first step is the recognition that this is a problem that needs to
> be solved in order for contracts to be viable in the real world.
>

I would like to understand this expectation a bit more. Rather than talking
about the details I would focus on the motivation.

The scenario that I am familiar with is that when a program P uses a
library L, it is likely that P will use L incorrectly, and additional
measures need to be taken to test if P is using L correctly. This would
mean that in the P2900 world we would want to runtime check the assertions
*at the library boundary* but not necessarily *inside* the library. IOW, If
I were the author of P, I would trust library L that it was
thoroughly tested, and would not want to assertion-test its implementation.
But I would like to test if I am *using* the library correctly. So I would
like to enable every precondition in L's interface and some contract_asset
statements close to library entry points that also function as
preconditions. But only those. If libstdc++'s STL implementation offers
control macros to enable STL-specific assertions, those assertions
practically check if the user is using the STL correctly: not if STL has
been correctly implemented.

But P3835 seems to be expressing a different need. So my question to the
authors of P3835 is: is your motivating use case testing the library
*usage* or really testing one library's implementation in a different way
than another library's implementation? If it is the latter, that would be
strange: you would have to mistrust the library L enough to want to keep
checking its implementation, but at the same time trust it enough that the
author put the right assertions in the right places with sufficient density.

Regards,
&rzej;