Date: Mon, 27 Oct 2025 02:37:23 +0200
On Mon, 27 Oct 2025 at 02:24, Joshua Berne <berne_at_[hidden]> wrote:
>
>
>
> On Sun, Oct 26, 2025 at 7:35 PM Ville Voutilainen via SG21 <sg21_at_[hidden]> wrote:
>>
>> On Mon, 27 Oct 2025 at 01:23, Herb Sutter via SG15
>> <sg15_at_[hidden]> wrote:
>> > Axiom: A fundamental property of contracts is that they are redundant – they never change the meaning of code.
>>
>> That axiom doesn't hold to begin with, unless you have contracts that
>> are guaranteed to have such a property.
>
>
> So build and run tools that do validate that particular contracts have your desired property. Or don't check and rely on your coding standards to achieve the same goal. How much you have faith in the "axiom" herb stated is based on how much you have faith in your developers to have not written very bad contract assertions and how much your tools warn you when you might have contract assertions that have such problems.
>
> Or apply static analysis tools only to a specific build with a specific set of evaluation semantics.
>
> Or apply them twice to both the build with all assertions checked (which will tell you when you have issues that you have identified as incorrect because you've put in contract assertions saying they are incorrect) and then again to be sure nothing slipped through the cracks because of differences in your production releases.
>
> There are many ways to analyze code with contracts --- all aided in being more useful because the contracts are actually written out in a way that the tools can understand --- and each way will benefit different users and use cases to different amounts.
It seems like there's a very good chance that we can get to a
non-violent agreement here.
Herb's axiom-corollary post is riddled with presumptions of the ilk
"this is (the only thing) what static analysis should do, these are
the things it can rely on,
and then it always does this-and-that".
And both of us say "no it isn't".
And I'm not saying "no it isn't, it instead always does this-and-that,
and that's the only thing it should do". I'm saying "no it isn't,
because there
are static analysis uses that don't have those presumptions, it
doesn't do what you describe, and it certainly shouldn't do what you
describe".
>
>
>
> On Sun, Oct 26, 2025 at 7:35 PM Ville Voutilainen via SG21 <sg21_at_[hidden]> wrote:
>>
>> On Mon, 27 Oct 2025 at 01:23, Herb Sutter via SG15
>> <sg15_at_[hidden]> wrote:
>> > Axiom: A fundamental property of contracts is that they are redundant – they never change the meaning of code.
>>
>> That axiom doesn't hold to begin with, unless you have contracts that
>> are guaranteed to have such a property.
>
>
> So build and run tools that do validate that particular contracts have your desired property. Or don't check and rely on your coding standards to achieve the same goal. How much you have faith in the "axiom" herb stated is based on how much you have faith in your developers to have not written very bad contract assertions and how much your tools warn you when you might have contract assertions that have such problems.
>
> Or apply static analysis tools only to a specific build with a specific set of evaluation semantics.
>
> Or apply them twice to both the build with all assertions checked (which will tell you when you have issues that you have identified as incorrect because you've put in contract assertions saying they are incorrect) and then again to be sure nothing slipped through the cracks because of differences in your production releases.
>
> There are many ways to analyze code with contracts --- all aided in being more useful because the contracts are actually written out in a way that the tools can understand --- and each way will benefit different users and use cases to different amounts.
It seems like there's a very good chance that we can get to a
non-violent agreement here.
Herb's axiom-corollary post is riddled with presumptions of the ilk
"this is (the only thing) what static analysis should do, these are
the things it can rely on,
and then it always does this-and-that".
And both of us say "no it isn't".
And I'm not saying "no it isn't, it instead always does this-and-that,
and that's the only thing it should do". I'm saying "no it isn't,
because there
are static analysis uses that don't have those presumptions, it
doesn't do what you describe, and it certainly shouldn't do what you
describe".
Received on 2025-10-27 00:37:39