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