On 4/16/2011 1:21 PM, bearophile wrote:
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.
When you combine that with allowing impure code, then yes it does.
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.
Yes. It leaves the onus of correctness on the user rather than the compiler.
That's what is required when doing, say, a printf.
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).
Any solution either breaks safety or is useless. A printf call breaks purity.
There is no way around that. A compiler switch cannot change that.
