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
