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

[Steven Schveighoffer]

On 6/20/20 2:04 PM, jmh530 wrote:
> On Saturday, 20 June 2020 at 14:51:32 UTC, Andrei Alexandrescu wrote:
>> [snip]
>>
>> I've been thinking of this for a while. The fact that input ranges 
>> must buffer one element (i.e. make front() callable several times) has 
>> been a gauche choice.
>>
>> Input ranges should have only one API:
>>
>> bool fetchNext(T& target);
>>
>> Fill the user-provided target with the next element and return true. 
>> At the end of the range, return false and leave the target alone.
>>
>> I'd considered this design back in the day but I was annoyed that it 
>> required a copy for ranges that in fact are better than input ranges 
>> (e.g. arrays etc).
>>
>> It's still a disadvantage, but over the years I realized there are not 
>> that many algorithms that only work on input ranges so we could 
>> make-do. Of those for which efficiency is a concern, they could easily 
>> be specialized for forward ranges.
> 
> That similar to what Steven Schveighoffer did in dcollections with cursors.
> 
> https://github.com/schveiguy/dcollections/blob/master/concepts.txt

Sorry, this is not the same.

Cursors are simply a way to refer to exactly one element, instead of 
using a begin and end element like a traditional container range would.

The advantage is that removing the "end" element (that has nothing to do 
with the range) won't invalidate the cursor.

What I wanted was the functionality of C++ iterators without the danger 
that comes with actually iterating them.

-Steve