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
