Memory allocation purity

[Dicebot via Digitalmars-d]

On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer 
wrote:
> On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad 
> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>
>> On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
>>> A little example of D purity (this compiles):
>>
>>> bool randomBit() pure nothrow @safe {
>>>    return (new int[1].ptr) > (new int[1].ptr);
>>> }
>>
>> Yes, and then you may as well allow a random generator with 
>> private globals. Because memoing is no longer sound anyway.
>
> This has nothing to do with allocators being pure. They must be 
> pure as a matter of practicality.
>
> The issue that allows the above anomaly is using the address of 
> something. There is a reason functional languages do not allow 
> these types of things. But in functional languages, allocating 
> is allowed.

Which is what makes D pure lint-like helper and not effective 
optimization enabler. This part of type system was under-designed 
initially, it should have been much more restrictive.

I am ok with current state though, it is just sad that it creates 
lot of false expectations from those familiar with pure 
functional languages.

> 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.

This is not true. Because of such code you can't ever 
automatically memoize strongly pure function results by compiler. 
A very practical concern.