Transient ranges

[Dicebot via Digitalmars-d]

On Tuesday, 31 May 2016 at 18:11:34 UTC, Steven Schveighoffer 
wrote:
>> 1) Current definition of input range (most importantly, the 
>> fact `front`
>> has to be @property-like) implies `front` to always return the 
>> same
>> result until `popFront` is called.
>
> Regardless of property-like or not, this should be the case. 
> Otherwise, popFront makes no sense.

Except it isn't in many cases you call "bugs" :(

>> 2) For ranges that call predicates on elements to evaluate 
>> next element
>> this can only be achieved by caching - predicates are never 
>> required to
>> be pure.
>
> Or, by not returning different things from your predicate.

It is perfectly legal for predicate to be non-pure and that would 
be hugely annoying if anyone decided to prohibit it. Also even 
pure predicates may be simply very expensive to evaluate which 
can make `front` a silent pessimization.

> This is like saying RedBlackTree is broken when I give it a 
> predicate of "a == b".

RBL at least makes certain demands about valid predicate can be. 
This is not case for ranges in general.

>> 3) But caching is sub-optimal performance wise and thus bunch 
>> of Phobos
>> algorithms violate `front` consistency / cheapness expectation
>> evaluating predicates each time it is called (liked map).
>
> I don't think anything defensively caches front in case the 
> next call to front is different, unless that's specifically the 
> reason for the range.

And that makes input ranges violate implication #1 (front 
stability) casually to the point it can't be relied at all and 
one has to always make sure it is only evaluated once (make stack 
local copy or something like that).


> I think we should be aware that the range API doesn't prevent 
> bugs of all kinds. There's only so much analysis the compiler 
> can do.

This is a totally valid code I want to actually work and not be 
discarded as "bug".