Caching in computing ranges

[Pelle]

On 10/09/2010 09:38 PM, 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?
>

How about never having caches and if you need them, you can get a 
cached(map(..etc..))?

I do not understand where the notion that ranges should have caches come 
from. It destroys the possibility for using const and complicates the 
writing of them.