== Quote from Andrei Alexandrescu (seewebsiteforem...@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.