Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Mon, 19 May 2014 15:03:55 -0400, Dicebot <public at dicebot.lv> wrote:

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

The code is incorrectly implemented, let me fix it:

bool oops() pure
{
   return false;
}

-Steve