On Mon, 19 May 2014 15:03:55 -0400, Dicebot <[email protected]> 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
<[email protected]> 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
