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
