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

[Avrina]

On Saturday, 20 June 2020 at 14:51:32 UTC, Andrei Alexandrescu 
wrote:
> 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.

Most of the algorithms in Phobos don't call front() multiple 
times and they make a copy. It is really annoying as this 
prevents using non copyable types or those that need to be moved, 
eg similar to unique_ptr. What you are suggesting doesn't sound 
all that better, it just cements what is already common place in 
Phobos into the API. It's usually not algorithms that are 
concerned with efficiency, but rather the type. If you implement 
an algorithm that you think doesn't need to be efficient but it 
does need to be for the type I am using it with, I don't think 
that'd any better than the situation we already have.