Proposal: takeFront and takeBack

[Jonathan M Davis]

On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
> takeFront implementation is dangerous for ranges which invalidates their
> front value when popFront is called, for instance, File.byLine. Thus
> takeFront will have to be used with care: any range implement takeFront
> (because of the template and USFC), but it may not be valid. That makes
> the range interface more complicated: There is a takeFront property, but
> you have to check it is safe to use... how do you check that by the way?

Hmm. I hadn't thought of that. That could be a good reason not to do this. I'm 
not quite sure how to get around that. Hmmm... It would arguably be a bit 
ugly, but a range which couldn't safely be used with takeFront could have an 
enum on it which indicated that, and takeFront would fail to compile if used 
with such a range. Of course, that would mean that you'd have to special case 
such ranges in any range-based function which used takeFront so that there was 
a branch which didn't use takeFront for ranges which couldn't use it.

I don't know. It's certainly something to think about. We may need a different 
solution.

> Are there so many ranges that duplicate efforts in front and popFront,
> where there is no easy workarround? Would it be such an improvement in
> performance to add takeFront? strings being immutable, my guess would be
> that it is not that hard for the compiler to optimize a foreach loop (it
> should be easy to profile this...). Even if there is an efficiency
> issue, you could easily solve it by implementing a range wrapper or an
> opApply method to make foreach faster. 

foreach isn't the problem. strings don't even use the range API for foreach. 
It's operating on them outside of foreach that's the problem.

- Jonathan M Davis