--- Comment #9 from deadalnix <> 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 =!(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:
------- You are receiving this mail because: -------

Reply via email to