Caching in computing ranges

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> On 10/9/10 14:38 CDT, Tomek Sowiński wrote:
> > I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
> > outermost range's cache is necessary; there's no way of accessing front() of
ranges deeper
> > in the expression twice because they are sealed by the outermost range. Example:
> >
> > map!"a._0 + a._1"(    // caches, front() may be called twice
> >     zip(    // oh, trumpet: front() is called only to compute outer map's cache
> >         map!"a*a"([2, 4, 5, 6]),    // oh, trumpet
> >         take(sequence!"a._0 + n * a._1"(1, 2), 4)    // oh, trumpet
> >     )
> > );
> >
> > Eliminating superfluous caches, among other benefits, allows inlining the
(usually cheap)
> > front()s. One way to do it is to parametrize computing ranges with an enum
Cached.(yes|no).
> > What you think?
> I think it's a good idea. In fact let's eliminate caching altogether; it
> does not happen for the random access operator anyway and I think it's
> fair to simply evaluate the function whenever an element is accessed.
> Whaddaya think?
> Andrei

Vote++.  When I added bidirectional support for map(), I felt like any solution
for doing bidirectional caching was going to suck.  I considered just eliminating
it, but left it because at the time I was more interested in just getting
bidirectional/random access working than worrying about the cache issue.  IMHO the
only range that should be cached is a Cached higher order range.