I'm back

[Jonathan M Davis]

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