std.range.chunk without length

[Stephan Schiffels]

On Thursday, 13 February 2014 at 17:41:37 UTC, monarch_dodra 
wrote:
> On Thursday, 13 February 2014 at 14:45:44 UTC, bearophile wrote:
>> Stephan Schiffels:
>>
>>> It would be actually easy to implement chunks without the 
>>> "save" function, by using an internal buffer, which would 
>>> however make this algorithm's memory burden linear in the 
>>> chunk size. Would that be acceptable?
>>
>> I think it's acceptable. But perhaps you need to add one more 
>> optional argument for the buffer :-)
>>
>> Bye,
>> bearophile
>
> Users andralex:
> https://github.com/D-Programming-Language/phobos/pull/1186
>
> And quickfur:
> https://github.com/D-Programming-Language/phobos/pull/1453
>
> Have submitted different algorithms for a similar problem: 
> Basically, bu being "2-dimensional lazy" (each subrange is 
> itself a lazy range). However, both come with their own 
> pitfalls.
>
> Andrei's still requires forward ranges. quickfur's doesn't, 
> and, arguably, has a simpler design. However, if I remember 
> correctly, it is also less efficient (it does double work). 
> Implementing Quickfur's solution in Chunks for input ranges 
> only could be a good idea.
>
> It *is* extra work, more code, more code to cover (that is 
> difficult to cover). I'm not sure we have the man power to 
> support such complexity: I was able to make chunks work with 
> forward ranges, but I still haven't even fixed Splitter yet! I 
> think that should take precedence.

Yeah, nevermind, I won't do it. I realised that you had good 
reasons to require a ForwardRange. Chunking really needs some 
sort of "save" implemented. And what I had in mind to make it 
work on File.byLine with a buffer is actually a hack that 
effectively adds "save" functionality to the InputRange… so I 
agree it's logically not reasonable to do it here.

Thanks anyway.
Stephan