Transient ranges
Dicebot via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jun 12 01:46:10 PDT 2016
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.
More information about the Digitalmars-d
mailing list