Transient ranges

[Seb via Digitalmars-d]

On Saturday, 28 May 2016 at 19:09:09 UTC, Stefan Koch wrote:
> On Saturday, 28 May 2016 at 17:27:17 UTC, Joseph Rushton 
> Wakeling 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.
>
> That is a rather sound idea.

I like this idea too!
`opApply` implies passing in a delegate which (if I am not 
mistaken) implies the use of GC at the moment and isn't as easy 
to optimize as `while (!file.empty) { writeln(file.front) }`