GC.malloc is pure - wat

[Steven Schveighoffer via Digitalmars-d]

On 4/24/15 5:07 PM, deadalnix wrote:
> On Friday, 24 April 2015 at 20:55:02 UTC, Steven Schveighoffer wrote:
>> But I can check memory usage size and see global state has been altered.
>>
>
> OK, if you want to play that game, don't access memory ever, that is
> global state. I mean, even if the memory is read only you may end up
> affecting the MMU, so that is definitively a no go. Also, you'd better
> have only a one instruction loop in your program as otherwise you'll
> affect the program counter, a definitively visible state from the user.

All I'm saying is that GC.malloc alters global state. I agree that it's 
OK to pretend that it doesn't because as long as you agree not to base 
things on this knowledge, you are fine calling pure functions that use GC.

It's possible to do things like this, to make pure functions "unpure":

bool foo() pure
{
    return new int(0) < new int(0);
}

We just agree to ignore that aspect. And I'm OK with it. As I'm OK with 
ignoring the bad things you can do with C malloc or C free that make 
things impure.

>>> When you free, you potentially alter references anywhere outside your
>>> "pure" function. It must not be pure.
>>
>> When you do ANYTHING to mutable data, you potentially alter references
>> outside your pure function. This is not a disqualifier. It's accessing
>> global sate directly that wasn't passed to you that is a disqualifier.
>
> pure function can access global immutable state that wasn't passed to
> it, so you may want to revise your definition.

Sure: s/accessing/altering, my mistake.

-Steve