assert semantic change proposal

[Atila Neves via Digitalmars-d]

This. 1000x this.

Atila

On Monday, 4 August 2014 at 01:17:23 UTC, John Carter wrote:
> On Sunday, 3 August 2014 at 19:47:27 UTC, David Bregman wrote:
>
>> 2. Semantic change.
>> The proposal changes the meaning of assert(), which will 
>> result in breaking existing code. Regardless of philosophizing 
>> about whether or not the code was "already broken" according 
>> to some definition of assert, the fact is that shipping 
>> programs that worked perfectly well before may no longer work 
>> after this change.
>
> Subject to the caveat suggesting having two assert's with 
> different names and different meanings, I am in the position to 
> comment on this one from experience.
>
> So assuming we do have a "hard assert" that is used within the 
> standard libraries and a "soft assert" in user code (unless 
> they explicitly choose to use the "hard assert"....)
>
> What happens?
>
> Well, I'm the dogsbody who has the job of upgrading the 
> toolchain and handling the fallout of doing so.
>
> So I have been walking multimegaline code bases through every 
> gcc version in the last 15 years.
>
> This is relevant because on every new version they have added 
> stricter warnings, and more importantly, deeper optimizations.
>
> It's especially the deeper optimizations that are interesting 
> here.
>
> They are often better data flow analysis which result in more 
> "insightful" warnings.
>
> So given I'm taking megalines of C/C++ code from a warnings 
> free state on gcc version N to warnings free on version N+1, 
> I'll make some empirical observations.
>
> * They have _always_ highlighted dodgy / non-portable / 
> non-standard compliant code.
> * They have quite often highlighted existing defects in the 
> code.
> * They have quite often highlighted error handling code as 
> "unreachable", because it is... and the only sane thing to do 
> is delete it.
> * They have often highlighted the error handling code of 
> "defensive programmers" as opposed to DbC programmers.
>
> Why? Because around 30% of the code of a defensive programmer 
> is error handling crud that has never been executed, not even 
> in development and hence is untested and unmaintained.
>
> The clean up effort was often fairly largish, maybe a week or 
> two, but always resulted in better code.
>
> Customer impacting defects introduced by the new optimizations 
> have been....
>
> a) Very very rare.
> b) Invariably from really bad code that was blatantly 
> defective, non-standard compliant and non-portable.
>
> So what do I expect, from experience from Walter's proposed 
> change?
>
>
> Another guy in this thread complained about the compiler 
> suddenly relying on thousands of global axioms from the core 
> and standard libraries.
>
> Yup.
>
> Exactly what is going to happen.
>
> As you get...
>
> * more and more optimization passes that rely on asserts,
> * in particular pre and post condition asserts within the 
> standard libraries,
> * you are going to have flocks of user code that used to 
> compile without warning
> * and ran without any known defect...
>
> ...suddenly spewing error messages and warnings.
>
> But that's OK.
>
> Because I bet 99.999% of those warnings will be pointing 
> straight at bone fide defects.
>
> And yes, this will be a regular feature of life.
>
> New version of compiler, new optimization passes, new 
> warnings... That's OK, clean 'em up, and a bunch of latent 
> defects won't come back as customer complaints.