Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/29/16 7:15 AM, Dicebot wrote:
> On 05/28/2016 08:27 PM, 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.
>
> I would prefer such ranges to not have `front` and return new item from
> `popFront` instead but yes, I would much prefer it to existing form,
> transient or not. It is impossible to correctly define input range
> without caching front which may not be always possible and may have
> negative performance impact. Because of that, a lot of Phobos ranges
> compromise `front` consistency in favor of speed up - which only seems
> to work because most algorithms need to access `front` once.

What problems are solvable only by not caching the front element? I 
can't think of any.

And there is no way to define "transient" ranges in a way other than 
explicitly declaring they are transient. There isn't anything inherent 
or introspectable about such ranges.

-Steve