[Issue 9674] std.algorithm.filter problems with non-deterministic _input.front

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9674



--- Comment #9 from timon.gehr at gmx.ch 2013-03-10 01:55:54 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #4 and #5)
> > > 
> > > > The code depends on front of the source range being consistent across calls.
> > > 
> > > front() is not tagged with "pure", ...
> > 
> > How would that help?
> 
> Pure _does_ make it consistent across calls. That's how it helps. :)

Actually it does not. :)

struct R{
   int x;
   @property int front()pure{ return x++; }
}

I guess you want const pure. (but there are still type system holes.)

> And arguably a range's front property - in theory - fits that shoe. As the user
> of a range I'd typically expect front to be a dumb, pure property.
> 
> In this case it is incorrect to call map with a mapping function that accesses
> global state for example.

One issue is that recalculation may be expensive, or it might be cheap, or even
removed by CSE.

> Or front has to cache the last result, so it doesn't
> need to ever be recalculated. But then practically every "front" property
> should be cached and it starts to look like a design flaw.

Agreed, it is not too clear what to do about this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------