Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/30/16 5:35 AM, Dicebot wrote:
> On Sunday, 29 May 2016 at 17:25:47 UTC, Steven Schveighoffer wrote:
>> What problems are solvable only by not caching the front element? I
>> can't think of any.
>
> As far as I know, currently it is done mostly for performance reasons -
> if result is fitting in the register there is no need to allocate stack
> space for the cache, or something like that. One of most annoying
> examples is map which calls lambda on each `front` call :
> https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L587-L590

Maybe my understanding of your post is incorrect. You said "It is 
impossible to correctly define input range without caching front which 
may not be always possible and may have negative performance impact."

I'm trying to figure out which cases caching makes the solution impossible.

>
>
>> 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.
>
> I don't really care about concept of transient ranges, it is the fact
> there is no guarantee of front stability for plain input ranges which
> worries me.

But this is inherent in languages which support mutable data. If you 
want data that doesn't change, require copied/unique data, or immutable 
data.

-Steve