assert semantic change proposal

via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 7 03:30:06 PDT 2014


On Wednesday, 6 August 2014 at 22:31:00 UTC, Walter Bright wrote:
> On 8/6/2014 5:14 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>> We're not living in an ideal world, unfortunately. It is bad 
>> enough that
>> programs are wrong as they are written, we don't need the 
>> compiler to transform
>> these programs to do something that is still wrong, but also 
>> completely
>> different. This would make your goal of fixing the program 
>> very hard to achieve.
>> In an extreme case, a small error in several million lines of 
>> code could
>> manifest at a completely different place, because you cannot 
>> rely on any
>> determinism once undefined behaviour is involved.
>
> You are technically correct, and I used to worry about that. 
> But after using assert()s for 30 years, I can only think of 
> this happening once. assert()s tend to trip very shortly after 
> the actual error occurred. Of course, there's a bit of an art 
> to appropriate placement of those assert()s.

But for those 30 years you only used asserts with the semantics 
they have in C, not with the semantics you want for D. I don't 
see how you can come to the conclusion that the same is true for 
the "new style" assertions.

The problems with finding errors that I talk about are not 
because the cause of the error is far from the assert. They stem 
from the fact that - with the proposed semantics - the asserts 
themselves can influence code in different parts of the program, 
far away from both the cause of the error and the failed assert.


More information about the Digitalmars-d mailing list