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.
