std.range.cacheFront proposal&working code: wraps a range to enforce front is called only once

[deadalnix]

On Thursday, 24 October 2013 at 19:50:44 UTC, Jonathan M Davis 
wrote:
> On Thursday, October 24, 2013 21:10:58 deadalnix wrote:
>> On Thursday, 24 October 2013 at 17:57:54 UTC, Jonathan M Davis
>> 
>> wrote:
>> > Now, that being said, I'd argue that map should probably be
>> > changed so that it
>> > calls its function on popFront rather than front (though that
>> > has the downside
>> > of requiring that it then hold the current value, which it
>> > doesn't currently
>> > have to do), but regardless, you're using map for something
>> > other than what it
>> > was designed to do.
>> 
>> That would break random access.
>
> No, it wouldn't. It would just require that the function be 
> called directly in
> the case of random access, so you then have the problem with 
> randomly accessed
> values that you really can't implement map in a way that avoids 
> a calling its
> function every time you randomly access a variable. It's one 
> more reason to
> consider not accessing the same element in a range multiple 
> times, but as it's
> pretty much a guarantee that at least some range-based code 
> will access front
> multiple times, it's not a good idea for the range to be 
> designed such that it
> can't reasonably handle having each element accessed multiple 
> times - which in
> the case of map would imply that the programmer using map 
> should make sure
> that the function they give it can handle being called multiple 
> times per
> element without changing the semantics of the code. It also 
> would imply that
> doing something like
>
> range.map!(a => new Aboject(a))
>
> like you do in another post should be done with great care if 
> at all, as there
> is a high risk that you will end up creating multiple objects 
> per element as
> you traverse the range unless you specifically make sure that 
> use foreach on it
> or immediately convert it to an array.
>
> - Jonathan M Davis

OK let me restate : it would give random access a different 
semantic than in order access. Which is undesirable.