On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote: > Here are two thoughts: > > 1. The notion of "this is an input range that is not a forward range, > AND the element type has mutable indirections so it's not a proper value > type" is a very close approximation of transiency. We could define that > as a trait and have interested algorithms consult it.
So basically, functions like std.array.array would require isInputRange!R && !hasTransientFront!R where hasTransientFront is false for forward ranges and is true for input ranges if front returns a mutable reference type or anything that might be a mutable reference type (since you can't always tell)? We'd probably have to add some sort of property for it to check for so that a range could declare that it didn't have a transient front (e.g enum notTransient = true;) so that there would be fewer cases where a range's front would be determined to be transient when it actually wasn't, but that wouldn't be hard. I think that that approach would be far more costly if it were not restricted to input ranges, but as so few ranges are not forward ranges and so many algorithms require forward ranges anyway, it wouldn't really complicate much, though it _is_ still another level of compliction to ranges. > 2. I'm reversing my attitude toward peekFront for the simple reason I've > been there: moveFront, moveBack, and moveAt. And it's not a pretty place > to be in. As soon as we're discussing peekFront there's the question of > supporting peekBack and peekAt. I'm pretty sure people, if sufficiently > motivated, will find examples of bidirectional and random-access > transitory ranges that motivate such primitives. It's not all bad in that in almost all cases, a free function peekFront could be used, making it so that almost no ranges would have to implement it. But I do tend to agree that it would be nice to not have to add more primitives. In fact, I'd actually like _reduce_ the number of primitives by gettting rid of moveFront and its brethren. They don't seem worth the extra complication to me. And even if the declarations for peekFront itself don't cost much, it _does_ mean that all ranges have to worry about whether they should use peekFront or front, which _does_ complicate things. So, I'm not completely enamoured with peekFront either. Then again, I quite like the approach of banning transient fronts altogether and insisting that anything which would have a transient front use opApply instead. Certainly, of the two options that you give here, I think that I currently prefer the first. - Jonathan M Davis
