Michel Fortin wrote:
On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu
<[email protected]> said:
An algorithm can fail in many silent ways if it misuses the range
interface. None of std.algorithm algorithms uses front naively.
Easy to say. How did you verify that?
It's simply a mistake I make very seldom if at all (I don't remember any
instance). The range interface is narrow, and algorithms are always
careful with how they use it.
The problem is very subtle: if you call front after popFront on
something like byLine which adds a buffer on top of another range, it'll
eat one or more element on the downstream range that will be lost if you
dispose of the filtering range. It won't have any effect on algorithms
using the filtering range in itself, only on those using both the
filtering range and the downstream range in tandem.
Subtle problems could occur with a variety of other ranges if some
algorithm messes them up.
So basically, if you have an algorithm that calls front after popFront,
that algorithm cannot be used reliably for ranges filtering a stream
when that stream is also used directly, or used via other filtering
ranges. There's no way to enforce that as it becomes the user's problem.
Whereas if input ranges only define 'take', it's pretty easy for the
compiler to tell you an algorithm needs a buffer, so you add an
intermediary buffer range yourself and you're now aware of the
consequences.
I like take (I actually called it getNext). There was just too much
aggravation in defining and using that interface. I've literally lost
nights over figuring it out, and couldn't. Searching for getNext on this
group will reveal some of the issues.
Andrei
