Memory allocation purity

[Dicebot via Digitalmars-d]

On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer 
wrote:
> 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.

No it is not. It is semantically valid code which does exactly 
what it was expected to do. Unless compiler optimization happens 
which will actually introduce a bug silently. It is optimization 
that is broken, not code itself.

And this is not some sort of imaginary code. `alloc` 
implementation may be located in some other static library and 
not available to compiler. It is likely to be not a plain `alloc` 
in real code but some utility function that creates and returns 
object internally.

In the end result is the same. You can't allow even object 
identity operator if memoization is to happen reliably.

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

Wrong again. It does not rely upon anything. It simply checks if 
two objects returned by two functions calls are identical. With 
zero assumptions about it.

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

What the hell are you speaking about? Getting two different 
results for a function depending on -O flag is not weird enough 
for you?

- Hey, this program produces a wrong output!
- But it doesn't wipe your system. You will be fine.

At this point it is hard to believe you are serious and not 
trolling.