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

[Stanislav Blinov]

On Monday, 29 June 2020 at 17:49:29 UTC, Paul Backus wrote:

> Are you referring to ranges like `byLine` that invalidate the 
> previous front when popFront is called?

Yes.

> If so, I don't see what difference it makes whether they're 
> implemented with next() or some other interface.

Efficiency. A given algorithm may need to stagger the range in 
order to preserve the head. To keep a `next()` interface and 
avoid buffer corruption, additional branch is needed for 
staggering (see [1]). This can be avoided by switching to 
front/popFront buffering where caller can explicitly announce 
they're done reading the element (not in the gist (yet)).

[1] 
https://gist.github.com/radcapricorn/d76d29c6df6fa822d7889e799937f39d#file-inputrange-d-L180

> Personally, I am concerned here with how to make ranges work 
> with D's `const` and `immutable` qualifiers. So the fact that 
> there may be mutable state out there somewhere in libc/the 
> kernel/the filesystem doesn't bother me.

I understand that. Forward ranges are good candidates for 
const/immutable. Input ranges though - I'd prefer to tread 
lightly there.