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