Temporarily disable all purity for debug prints

Walter Bright newshound2 at digitalmars.com
Sat Apr 16 14:19:24 PDT 2011


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.


More information about the Digitalmars-d mailing list