Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Mon, 19 May 2014 13:44:59 -0400, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:

> On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
>> Returning the same immutable object, when called with the same  
>> immutable parameters, should never cause a break in code, pure or not.
>
> This isn't at all obvious to me. Also I think the "coin flip trick"  
> represent a class of algorithms that depend on imposing a sort order on  
> objects.

Anything that uses the order of unrelated addresses is incorrect outside  
of the heap code itself.

> I can easily see an algorithm break if you sometimes receive the same  
> object and sometimes receive a new object with the same values as  
> parameters.

Then you should have no problem producing an example, right?

> That's how an optimizer works, sometimes it optimizes, sometimes not. If  
> your algorithm depends on running something twice and then comparing the  
> two results then it could easily break.

The whole POINT of pure functions is that it will return the same thing.  
The fact that it lives in a different piece of memory or not is not  
important. We have to accept that. Any code that DEPENDS on that being in  
a different address is broken.

For instance, I would consider it fully possible and reasonable, and to  
only break already-broken code (except for testing implementation, which  
would have to change anyway), to make idup just return the argument if the  
argument is immutable.

-Steve