buffered input

[Robert Jacques]

On Sat, 05 Feb 2011 17:22:01 -0500, Nick Sabalausky <a at a.a> wrote:

> "Heywood Floyd" <soul8o8 at gmail.com> wrote in message
> news:mailman.1318.1296941395.4748.digitalmars-d at puremagic.com...
>>
>> As in, you've built some library that passes around ranges, but then  
>> some
>> part of it is slow and needs buffered ones. Isn't the point that you can
>> then swap out your ranges for buffered ones here and there, but  
>> continue to
>> have a functioning library?
>
> The problem with that is that in many many cases it forces unnessisary
> copying. We can get much better performance with this slightly more
> "hands-on" version. But that said, if the traditional "hands-free  
> automatic
> buffering" really is all you need, then such a thing [should] be easily  
> to
> construct out of the Andrei's style of buffered range.
>
>
>> Then follows that popFront() means "discard the first _element_, so that
>> the element that was second now becomes first." And if we can agree to
>> that, then shiftFront() is possibly very confusing, and so is
>> appendToFront(). They sound like they operate on the first element!
>
> I completely agree. The names of those functions confused the hell out  
> of me
> until I read Andrei's descriptions of them. Now I understand what they
> do...but I still don't understand their names at all.

See point of Andrei's post:
1. R is an input range of T[]
Which means that front returns an array, not a single element. So they  
sound like they operate on the first element, because that's exactly what  
they do. Conceptually, you need to think of buffered inputs as range of  
ranges, not a range of elements.