Memory allocation purity

[luka8088 via Digitalmars-d]

On 15.5.2014. 17:24, Andrei Alexandrescu wrote:
> On 5/15/14, 3:31 AM, luka8088 wrote:
>> Yeah, I read all about weak/string purity and I do understand the
>> background. I was talking about strong purity, maybe I should pointed
>> that out.
>>
>> So, to correct myself: As I understood strong purity implies
>> memoization. Am I correct?
> 
> Yes, as long as you don't rely on distinguishing objects by address.
> 
> Purity of allocation is frequently assumed by functional languages
> because without it it would be difficult to get much work done. Then,
> most functional languages make it difficult or impossible to distinguish
> values by their address. In D that's easy. A D programmer needs to be
> aware of that, and I think that's fine.
> 
> 
> Andrei
> 
> 

Hm, this does not seem right. @safe prevents you from taking the address
of of a value, as stated in
http://dlang.org/function.html#safe-functions , shouldn't pure do the same?

Reading again through the @safe docs it seems to me that purity (both
strong and weak) should imply @safe.

I have seen many claims that in D pure means something else from what it
means in functional languages and I think that it is too bad if there is
not going to be functional language alike purity in D. I have not seen
any example of something that can't be forbidden by the compiler if such
support would considered.