Memory allocation purity

[Dicebot via Digitalmars-d]

On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer 
wrote:
> On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad 
> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>
>> On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer 
>> wrote:
>>> It shouldn't matter. Something that returns immutable 
>>> references, can return that same thing again if asked the 
>>> same way. Nobody should be looking at the address in any 
>>> meaningful way.
>>
>> I think this is at odds with generic programming. What you are 
>> saying is that if you plug a pure function into an algorithm 
>> then you have to test for "pure" in the algorithm if it is 
>> affected by object identity. Otherwise, goodbye plug-n-play.
>
> I think I misstated this, of course, looking at the address for 
> certain reasons is OK, Object identity being one of them.

immutable(Object*) alloc() pure
{
     return new Object();
}

bool oops() pure
{
     auto a = alloc();
     auto b = alloc();
     return a is b;
}

This is a snippet that will always return `true` if memoization 
is at work and `false` if strongly pure function will get 
actually called twice. If changing result of your program because 
of silently enabled compiler optimization does not indicate a 
broken compiler I don't know what does.