Transient ranges

[Brad Roberts via Digitalmars-d]

On 5/28/2016 10:27 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote:
>> On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
>>> So what about the convention to explicitely declare a `.transient`
>>> enum member on a range, if the front element value can change?
>>
>> Honestly, I don't think that supporting transient ranges is worth it.
>
> I have personally wondered if there was a case for a TransientRange
> concept where the only primitives defined are `empty` and `front`.
>
> `popFront()` is not defined because the whole point is that every single
> call to `front` will produce a different value.

Um. that's wrong, just look at byLine as evidence.  It is popFront that 
changes the value to the 'next' one in the iteration.  Front called 
twice in a row does NOT change the value, and shouldn't.  I think you're 
misunderstanding something.