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. 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).
This is a totally valid code I want to actually work and not be
discarded as "bug".
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!
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.
