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