std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

[Joseph Rushton Wakeling]

On Saturday, 27 June 2020 at 20:14:36 UTC, Stanislav Blinov wrote:
> Equality is very much part of the struct interface though. I'll 
> restate. What about input.tail.empty == input.tail.empty? Or 
> input.tail.front == input.tail.front? Or, speaking of ranges, a 
> input.tail.equal(input.tail)?..

Does it even make _sense_ to be able to call `tail` twice on the 
same input range instance?

> If the explanation is "`tail() const` is impure, and calling it 
> repeatedly with the same `this` produces different results,
> even when `this` is immutable", "WTF???" would be quite a 
> reasonable follow-up question.

One of the problems with thinking about ranges -- and the current 
range API reflects this -- is that it tends to start by thinking 
about deterministic examples (e.g. arrays).  But while some input 
ranges may be deterministic in practice, it is not possible to 
reasonably assume "same input, same output" behaviour.  That's 
the whole _point_ of input ranges.

As an example: reading a stream of values from a crypto RNG, or a 
"true random" source measured from some ongoing physical process.

A key thing to observe there is that, immutable or no, the state 
of `this` doesn't give you complete information about what comes 
next in the sequence, and indeed the result may also depend on 
precisely _when_ the next element is requested (e.g. if my input 
range is a "true random" noise source, I'm likely to get a 
different value if I wait 0.1 sec to call it rather than calling 
it right now, even if no one else has been using that noise 
source).

Conceptually that doesn't fit very well with the concept of 
`tail`, but that's just a matter of a better name.  The real 
problem here isn't the indeterministic results, it's the idea 
that the original `this` is usable after `tail` has been called 
on it that is the problem.