On Mon, 19 May 2014 23:33:30 -0400, Jonathan M Davis via Digitalmars-d
<[email protected]> wrote:
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d <[email protected]>
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;
}
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
