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 15:07:21 UTC, H. S. Teoh wrote:
> On Sun, Jun 28, 2020 at 02:00:42PM +0000, Stanislav Blinov via 
> Digitalmars-d wrote: [...]
>> What makes an input range distinct is that, unlike other 
>> kinds, it can only be consumed once - there's no need for any 
>> other assumptions. The current range API does not enforce this 
>> in any way, hence the copying conundrum and Jonathan's "don't 
>> use original after you make a copy" or other similar 
>> statements that amount to "you should know what you're doing".
>
> This is not a sufficient assumption, because there remains the 
> question of what state a range should be in after you iterate 
> over it partially, say, using a foreach loop:
>
> 	MyRange r = ...;
> 	foreach (e; r) {
> 		if (someCondition) break;
> 	}
> 	foreach (e; r) {
> 		// Do we get the remaining elements of r here, or do we
> 		// get all the elements from the beginning again?
> 	}

> Even if we grant that r is a forward range, the semantics of 
> the above code is still underspecified.

Of course it isn't, because there's a problem with `foreach`. It 
iterates over a copy, except if there's an opApply. I'm not sure 
what your argument is. I repeat: "The current range API does not 
enforce [input range behavior] in any way, hence the copying 
conundrum..." `foreach` is very much a part of range API.

> And it's not just a matter of specifying that the semantics 
> should be; there's also the question of whether we should 
> specify anything at all, keeping in mind that the more specific 
> the definition, the less room there is for efficient 
> implementation of ranges (i.e., some optimizations may be 
> excluded if there are too many semantic requirements on ranges).

Yes, we should. For example, non-copyability of input ranges, 
which enables *more* efficient implementations (whereas expecting 
them to remain copyable dictates the opposite).

> ...there is a great deal of advantage in using the subset of 
> semantics in which input ranges *are* subsets of forward 
> ranges, because this allows us to unify a lot of iteration 
> logic.

That's not based on range semantics, it's based solely on 
interface. An input range and a forward range can have the same 
interface for iteration, i.e. a `fetchNext` or its variant. The 
only difference is that you can't fork the former.

> Otherwise, like you say below, every algorithm will need to be 
> duplicated, once for input ranges, once for forward ranges, 
> which will instantly double the size of Phobos algorithms.

That's a gross exaggerration. Algorithms already do the semantic 
duplication, for arrays, for hasLvalueElements, etc., etc., 
ultimately, when everything else fails, arriving at the "while 
(!r.empty) r.popFront()".