[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


Marco Leise <Marco.Leise at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Marco.Leise at gmx.de


--- Comment #8 from Marco Leise <Marco.Leise at gmx.de> 2013-03-09 18:08:45 PST ---
(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. :)
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. 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.

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