Memory allocation purity

[Jonathan M Davis via Digitalmars-d]

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, but it could be used in far more complex situations that don't involve
doing equality checks when two objects aren't the same.

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.

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.

- Jonathan M Davis