Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:

> On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer wrote:
>> To be honest, code that would exploit such an anomaly is only ever used  
>> in "proof" exercises, and never in real code. I don't think it's an  
>> issue.
>
> That's the wrong attitude to take when it comes to the compiler and  
> runtime.

There are always ways around the guarantees. This one isn't as detectable,  
since there is no "red-flag" cast or attribute. But I see no utility in  
such code.

> If it verifies, it should verify. Not mostly, but fully, otherwise  
> "weakly pure" becomes a programmer guarantee. Which is ok too, but  
> either the one or the other.

Memory allocation is an exception to purity that is widely considered OK,  
because of the practical need for allocating memory from a heap to do  
work. In general, it's the block of data that is important, not it's  
address. Where it comes from is of no consequence.

> How can you prove that such issues don't arise in real code?

Of course I can't prove it doesn't arise, but I can't think of any use  
cases to do something significant based on the address of heap data in  
relation to another unrelated heap block.

Perhaps you can show a use case for it?

The other thing to think about is that such code won't serve the purpose  
for which it was written! randomBit won't be random because it will likely  
be memoized.

In any case, the alternative is to have D pure functions avoid using  
pointers. It's as drastic as that.

-Steve