I'm back

[Andrei Alexandrescu]

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.


Andrei