Le 13/11/2012 00:57, Andrei Alexandrescu a écrit :
On 11/12/12 3:14 PM, Jonathan M Davis wrote:
On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
Topic on range transience probably, as it is
almost concluded.
I'm leaning toward doing nothing about this.
As it stands, most everything assumes that front is not transient. But
then we
have ByLine and ByChunk. So, they just plain don't work as ranges for
the most
part, but they're in the standard library. Either they need to stop being
transient or to stop being ranges (and use opApply), or we need to
decide on a
way to support them being transient as ranges.
The best options at this point seem to be to either insist that all
ranges have
non-transient fronts (and adjust ByLine and ByChunk accordingly) or to
go with
the peekFront idea. The peekFront idea probably needs some examination
though
in order to work on the kinks (e.g. letting peekFront and front return
different
types might be useful in some circumstances, but in general, it's
likely to
cause a lot of problems if they don't both return ElementType!R).
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.
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.
I understand your point, so why not simply state that range MUST NOT be
transient at all ? This is the solution that introduce nothing.
