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

[Petar]

On Saturday, 20 June 2020 at 10:52:37 UTC, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 10:03:06 UTC, Petar Kirov 
> [ZombineDev] wrote:
>> On Saturday, 20 June 2020 at 09:49:38 UTC, Stanislav Blinov 
>> wrote:
>>> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>
>>>> 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 suppose that postblit has had various implementation and 
>> language design issues (which copy constructors address), 
>> which prevented them from being a reliable alternative to 
>> save(). This and probably also class support.
>
> All ranges are supposed to be copyable, so their copy-ability 
> is not sufficient to distinguish input and forward ranges. 
> Whether it's postblit or copy ctor makes no difference here, 
> unless I'm missing something.

As far as I know, back when the ranges API was worked on postblit 
ctors didn't work reliably, so .save() was the only option. If it 
had worked, we could require that non-forward ranges are 
non-copyable.