On Mon, 19 May 2014 16:23:34 -0400, Dicebot <[email protected]> wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer wrote:
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
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
