Walter:
> No, it is not. You seem to be thinking that purity is just a bug finding or
> optimization feature. That is not so. Purity is a guarantee that can be relied
> upon for a program's behavior. Breaking purity breaks that guarantee.
>
> (Think multithreaded programs, for example.)
I was not thinking about multi-threaded programs, you are right.
But I think just "commenting out" the pure attributes doesn't turn a correct
multi-threaded program into an incorrect one.
>> If you take a D2 program, you remove all its pure attributes and you compile
>> it again, the result is generally a program just as correct as before.
> "generally" is not a verifiable characteristic. When we talk about safety,
> we're
> talking about a verifiable guarantee.
Your solution too (of allowing impure code inside debug{} is breaking the
guarantees.
With "generally correct" I meant to say that if you use the -nopure switch then
the program is as correct as before, but in some uncommon cases it doesn't
compile, because it doesn't satisfy some static requirements of purity that it
contains. A not compiled program is safe :-) So while my solution was not
perfect, I think your solution is less safe than mine.
My purpose was to present a debugging problem I have had, to suggest one
solution, and to try to explain why my solution isn't breaking safety (unlike
yours). I think you have now understood my ideas. You have more programming
experience than me, the design decision is yours. Thank you for giving one
solution to the original debug problem, and for your answers in this thread.
Bye,
bearophile
