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

[Stanislav Blinov]

On Sunday, 28 June 2020 at 14:12:39 UTC, Paul Backus wrote:

> It sounds like what you are really trying to say here is that 
> input ranges and forward ranges should not use the same 
> interface, and that input ranges should instead implement only 
> `Option!T next()`.

Not exactly. A given forward range may also implement such a 
`next`. Taking your example, with a seekable file and `pread`. 
Which would, of course, narrow the set of "files" it would be 
able to work with. A forward range need not, necessarily, have a 
`front` and a `popFront` (see that funky List that Andrei posted 
a while back). We should differentiate by some other artifact. I 
maintain that artifact should be copyability. Or we can keep the 
distinction based on the presence of save(), and live forever 
with the ambiguous semantics and the "don't use original after 
copy unless you know what you're doing" convention (yuck). Are 
there even other options besides accepting UB?

> My example was a response to the specific claim that "an 
> immutable input range cannot exist." Specifically, it was a 
> counterexample demonstrating that the claim is false. As I'm 
> sure you can see, the claim is still false even if we agree to 
> use next() instead of tail() for input ranges, since next() is 
> obviously allowed to be impure.

I can't see that. I don't see how you're falsifying that claim 
when in order to implement the range you need mutable state. 
"It's mutable, but the compiler can't see that, therefore it's 
immutable" - that is a dangerous justification. There are indeed 
some legitimate applications for it (allocators, mutexes), but 
this isn't one of them. If `a.tail` is not returning the tail of 
`a`, then it's either a bug in the design (shouldn't be called 
`tail`) or in the implementation (should not mutate *any* state).