Le 13/11/2012 01:57, Jonathan M Davis a écrit :
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.
I never used moveFront and alike.
