Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Mon, 19 May 2014 16:23:34 -0400, Dicebot <public at dicebot.lv> wrote:

> On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer wrote:
>> 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
>
> Oh, and are probably eager to show me links to specs which indicate what  
> part of my snippet breaks the type system? Is it allocation that is  
> forbidden in reasonable code? Or object identity?

None is forbidden, and the combination above is a BUG. Bugs happen,  
compilers actually compile them. pure != bug-free.

> Please stop this "write proper code" absurdism. This code is safe,  
> doesn't use casts or pointer forging or any other dirty low level  
> tricks. If compiler can't reject it as invalid and goes into funny mode  
> instead, compiler is fucked. There can be no excuse for it.

The code above relies on implementation details of the allocator to do  
it's work. It's invalid to do so.

Please show me the code that goes into "funny land" because of an  
incorrect result of oops.

I suppose it looks like this:

if(oops())
{
    system("rm -rf /");
}

The example is meaningless, because it uses a ridiculous method to  
calculate false.

Honestly, the above code COULD be written like this:

immutable(Object) alloc() pure
{
    static immutable o = new immutable(Object);
    return o;
}

And be just as valid (and more efficient).

-Steve