Transient ranges

[Joseph Rushton Wakeling via Digitalmars-d]

On Saturday, 28 May 2016 at 21:32:15 UTC, Brad Roberts wrote:
> 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.

I'm not talking about how byLine currently behaves.  I'm talking 
about a meaningful API that could be used for a range that (by 
design) has a transient front, that would be unambiguous in its 
behaviour.