[Issue 8803] map.filter.array run map delegate an incorrect number of time.

[d-bugmail at puremagic.com]

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



--- Comment #9 from deadalnix <deadalnix at gmail.com> 2012-10-17 05:24:12 PDT ---
(In reply to comment #8)
> (In reply to comment #7)
> > Well, I do think many valid uses include impure functions, even in sort. For
> > instance for benchmarking purpose, for educational purpose, for caching.
> > 
> > More importantly, pure function isn't enough. A pure function can return 2
> > different objects. Even if the object's content will be the same, its identity
> > will not, which is a problem in many cases (the example above is simplified, in
> > my case that was the issue).
> 
> I think this issue boils down to this: you are expecting something from map,
> which is does not advertise to do (any more). There is no bug.
> 
> You could change this to an enhancement request, because you are asking for an
> additional feature.
> 

That wasn't an additional feature. Using such method, it is easy to solve the
entire bug database within the day.

The spec was made that way for good reason : this is how map works in every
single language that have map and allow side effects.

This violate the least principle and expose filter and map internals.

> Note that if you do add caching for 'front', you still have the same problem if
> you try to use indexing. e.g.
> 
> auto xs = [1, 2, 3];
> auto m = xs.map!(fun)();
> auto ref a = m[1], b = m[1];
> 
> The only way this could guarantee to apply fun once is if it caches the entire
> range, which is totally impractical.

This can be solved by caching only 0 .. index . Or by caching within filter and
not map.

Or eventually by stating that this is not doable for indices. Most languages
don't allow index on map or create a temporary array automatically.

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