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

[Andrei Alexandrescu]

On 6/20/20 8:38 PM, Stanislav Blinov wrote:
> On Sunday, 21 June 2020 at 00:05:01 UTC, Andrei Alexandrescu wrote:
>> On 6/20/20 12:41 PM, Stanislav Blinov wrote:
>>> Being able to call front() several times does not necessitate the 
>>> *range* being buffering.
>>
>> If one calls front() twice without advancing the range, where does the 
>> range return the value from?
> 
> The most primitive example? The range is lazy and builds the element on 
> every call. But I believe I've tried to make the distinction clear: 
> *range* itself isn't necessarily buffering. Whatever it's iterating over 
> may have to.
> 
> And, in case that wasn't clear either, I understand perfectly where 
> you're coming from, since typical input ranges do indeed have to memoize 
> that nasty first element upon initialization (and since they have to do 
> that, they have to repeat that for every element thenceforth). Thing is, 
> the input stream
> 
> `bool fetchNext(ref T);`
> 
> does not solve this problem, it merely shrugs it off unto the caller, 
> with precarious consequences, as demonstrated.

I appreciate there's no shortage of people who teach my design and my 
code back to me. I honestly do, a lot.

It's unclear that much of anything, was demonstrated. Was the better 
alternative to make input ranges noncopyable? It only takes a couple of 
hours of coding a bit of that up to see it's quite onerous.