Transient ranges

[Dicebot via Digitalmars-d]

On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer 
wrote:
>> It only strengthens my opinion that Phobos is not a standard 
>> library I
>> want. Really, many of those issue would have been solved if 
>> basic input
>> range was defined as `empty` + `ElementType popFront()` 
>> instead.
>
> This doesn't solve the problem. empty may not be knowable until 
> you try to fetch the next element (for instance, i/o). A better 
> interface would be bool getNext(ref ElementType), or 
> Nullable!ElementType getNext(), or tuple!(bool, "eof", 
> ElementType, "value") getNext().

Not necessarily, one can simply define that range processing 
requires checking `empty` both before and after getting next 
element (and that returned value is undefined if empty == true).

Though I do agree that returning `Optional!ElementType` would be 
even better.

> Yes, I can see good reason why you would want this. Hm... a set 
> of adapters which reduce a range to its lesser API would be 
> useful here:
>
> array.asInput.map
>
> But an expectation for map should be that you want it to be 
> exactly the same as the original, but with a transformation 
> applied to each fetch of an element. I think it needs to 
> provide random access if random access is provided to it.

That is matter of design philosophy. For me such basic library 
primitives warrant C++ attitude of "don't pay for what you don't 
ask for" - and everything else, including actual feature 
completeness, is of negligible importance compared to that. If 
keeping random access for map requires either caching or multiple 
evaluations of predicate, I want it to be banned by default and 
enabled explicitly (not sure what could be good API for that 
though).

Phobos indeed doesn't seem to make such priorities right now and 
that is one of reasons I am growing increasingly unhappy with it.

>>> Then it's not a bug? It's going to work just fine how you 
>>> specified
>>> it. I just don't consider it a valid "range" for general 
>>> purposes.
>>>
>>> You can do this if you want caching:
>>>
>>> only(0).map!(x => uniform(0, 10)).cache
>>
>> Good advice. Don't want bugs with non-stable results and 
>> accidental
>> double I/O in your long idiomatic range pipeline? Just put 
>> "cache" calls
>> everywhere just to be safe, defensive programming for the win!
>
> Strawman, not what I said.

But that is what your answer meant in context of my original 
question :) My complaint was about existing semantics are being 
error-prone and hard to spot - you proposed it by adding more 
_manual_ fixup, which kills the whole point.