Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 07:02:58PM +0200, Jonathan M Davis wrote:
> On Tuesday, October 16, 2012 06:30:53 H. S. Teoh wrote:
[...]
> > I'm not saying that this should be the "correct" behaviour, but the
> > current definition does not prohibit a range from, say, reusing an
> > array to compute its next element. For example, one may have a range
> > that returns the permutations of a given array, in which popFront()
> > permutes the elements in-place. In this case, .front will become
> > invalid once popFront() is called. Many of the current range-based
> > functions will not work correctly in this case.
> > 
> > Of course, it's arguable whether such ranges should be admissible,
> > but as far as the current definition goes, I don't see anything that
> > states otherwise. If we don't make such things clear, then we're
> > bound to run into pathological cases where bugs will creep in
> > because of unstated assumptions in the code.
> 
> There's only so much that the compiler can check for you. Sure, we
> could say in the docs that front must still be valid after a call to
> popFront (and perhaps we should), but there's no way to validate that.

I wasn't talking about compiler validation. I was talking about clearly
defining, in the docs or otherwise, what exactly a range is, and what is
expected of it. Right now, it's rather nebulous what exactly constitutes
a range. I thought byLine() was a perfectly valid range, but apparently
you think otherwise. The two aren't compatible, since they lead to wrong
code that has buggy behaviour when passed something it doesn't expect.


[...]
> So, if we have expectations about how ranges should/must work, then
> that should be in the docs somewhere, but the definition of a range
> from the compiler's perspective can only ever be defined by eponymous
> templates which can't possibly verify correct behavior, meaning that
> something like ByLine will always be permitted even if it doesn't
> work, because it breaks the semantic design of ranges.
[...]

So what is (or should be) the semantic design of ranges? Let's work out
a precise definition so that we have something to build on.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel