Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 6/3/16 4:37 AM, Dicebot wrote:
> On Wednesday, 1 June 2016 at 01:31:53 UTC, Steven Schveighoffer wrote:
>> If you want to use such "ranges", the compiler will not stop you. Just
>> don't expect any help from Phobos.
>
> 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().

I've said many times, i/o is not conducive to ranges. You have to 
shoehorn it, which is fine if you need compatibility, but it shouldn't 
be a mechanism of low-level implementation. And you should expect some 
cruft here because of that.

> Some
> more - if algorithms didn't try to preserve original range kind unless
> they can do it with no overhead (i.e. arrray.map should not be a random
> access range out of the box).

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.

>> 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.

> Existing situation is bug prone exactly because you have no idea if you
> need to cache or not unless you try out specific combination of
> algorithms / predicates / input and carefully check what it does.

Again, yes, it's still possible to write code with bugs. The compiler or 
range library can only hold your hand so much.

I don't know of a library that's impossible to use incorrectly. 
Especially ones that let you execute arbitrary code internally.

-Steve