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

[Joseph Rushton Wakeling]

On Sunday, 28 June 2020 at 11:33:39 UTC, Stanislav Blinov wrote:
>> Does it even make _sense_ to be able to call `tail` twice on 
>> the same input range instance?
>
> No, it does not, that's my point. "Don't do that" isn't the 
> answer. "Can't do that" (statically disallowed, not present in 
> the interface) is the answer.

Indeed.  You seem to be thinking I'm disagreeing with you, when 
actually we are in agreement on this point ;-)

>> 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).
>
> Arrays are random access ranges (which are also forward). 
> They're not input ranges :)

That's not strictly true: one can reasonably _interpret_ an array 
as an input range if that's what is desired.  What makes an input 
range distinct is not whether the actual elements come from some 
impure input source (it can be deterministic under the hood, 
whether from iterating over array elements, or a deterministic 
generative mechanism like a PRNG, or whatever), but what 
assumptions the caller can make about how to use and interact 
with it.

> The current range API incorrectly treats any range as at least 
> an input range. If we are talking about making changes to range 
> API - that is one of the changes that needs to be made.

That doesn't really make sense to me.  Why is it not possible to 
interact with any other range via input range semantics?

>> 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.
>
> Yes, that is why an input range cannot be implementing `tail`. 
> You cannot keep the original range *and* the tail. That's what 
> forward ranges do.

Right, _you cannot keep the original range and the tail_.  But 
that doesn't block you having a method which takes the original 
range as input, and returns the updated range.  The issue is 
stopping you using the _original_ range (e.g. requiring it to be 
passed into the method via a move rather than by reference?).