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

[Andrei Alexandrescu]

On 6/20/20 5:49 AM, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via 
>> Digitalmars-d wrote: [...]
>>> One good goal for std.v2020 would be to forego autodecoding throughout.
>> [...]
>>
>> Another could be to fix up the range API -- i.e, reconsider the 
>> ugliness that is .save, now that D has copy ctors.
> 
> How do you see that? Fundamentally, what have copy ctors changed in this 
> regard?

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.