Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 11:17:08AM -0400, Andrei Alexandrescu wrote:
> On 10/16/12 1:59 AM, Jonathan M Davis wrote:
> >On Monday, October 15, 2012 22:48:15 Jonathan M Davis wrote:
> >>So, I don't really know what the right answer is, but I _really_
> >>don't like the idea of having to worry about the result of front
> >>changing after a call to popFront in every single function that ever
> >>uses front. In the general case, I just don't see how that's
> >>tenable. I'd _much_ rather that it be up to the programmer using
> >>abnormal ranges such as ByLine to use them correctly.
> >
> >And actually, it seems to me that issues like this make it look like
> >it was a mistake to make ranges like ByLine ranges in the first
> >place. They should have just defined opApply so that they'd work
> >nicely in foreach but not with range- based functions. They're
> >clearly not going to work with a _lot_ of range-based functions.
> 
> I think integration of pure streams within ranges is important and
> beneficial.
[...]

I agree, and I think that's what makes ranges such a powerful concept.
I'd hate to lose it just over implementation details like popFront()
pulling the carpet from under a few functions that assume the
persistence of what .front returns. I'd much rather live with an
isTransient property (which is only needed in a very few cases, and only
needs to be checked in a handful of places where the dependence matters,
and so is not a big inconvenience at all), than to devolve into Java's
wrapper upon adapter upon wrapper design.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.