Transient ranges

[Dicebot via Digitalmars-d]

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.

I believe this is biggest issue in D ranges design right now, by large
margin.