Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Mon, 19 May 2014 23:33:30 -0400, Jonathan M Davis via Digitalmars-d  
<digitalmars-d at puremagic.com> wrote:

> On Mon, 19 May 2014 15:20:46 -0400
> Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
> 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;
>> }
>
> Sure, that particular example may be contrived, but there's plenty of  
> code out
> there that checks for whether two objects are the same object. A classic
> example would be for skipping equality checks if the two objects are the  
> same
> object

If anything, the optimization will make this more efficient.

> , but it could be used in far more complex situations that don't involve
> doing equality checks when two objects aren't the same.

This is hand-waving. I need a real example to understand.

> The reality of the matter is that regardless of whether you think that
> checking two objects to see whether they're the same object is a valid
> operation or not, it's perfectly legal to do so and _will_ happen in  
> code, so
> if the compiler makes optimizations which will change whether two  
> objects are
> the same object (e.g. optimizing out a second call to a pure function  
> within
> an expression so that the result is reused in spite of the fact that the
> function returns a new object each time it's called), then the result is  
> that
> the semantics of the program have changed due to an optimization. And  
> that is
> most definitely a bad thing.

How so? What exactly happens when two identical, but immutable objects,  
are optimized into being the same object?

> IMHO, if the compiler cannot guarantee that a pure function returns the  
> same
> object every time if it returns a reference type, then the compiler  
> should
> never optimize out multiple calls to that function. To do otherwise would
> make it so that the semantics of the program change due to an  
> optimization.

General reference type, yes. Immutable reference type, no.

-Steve