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.
