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

[Stanislav Blinov]

On Saturday, 20 June 2020 at 13:01:33 UTC, Petar Kirov 
[ZombineDev] wrote:

> You mean that array.dup doesn't work if the element type uses 
> copy constructors? I haven't checked so I guess it's a problem 
> indeed, though this shouldn't affect the ranges themselves 
> (i.e. array slices).

Yes, Razvan Nitu is working on a fix for .dup already. But 
there's lots more. The ~= also doesn't call copy ctor. Nor does 
copying of slices and static arrays, i.e.

S[10] arr;
auto brr = arr; // no copy ctors called
arr[0 .. 2] = arr[2 .. 4]; // no copy ctors called

While .dup/.idup are a druntime-only fix, the rest requires fixes 
in the compiler.

It may be of small concern to ranges themselves (barring 
ranges-of-ranges), but a concern nonetheless.

> Yeah, I know. Though input-only range are odd in general. I 
> think they can only work well either if the code moves them 
> around, or if they use reference semantics (classes or 
> refRange).

But if they *do* use reference semantics, they need be copyable 
(see e.g. std.stdio.ByLineImpl). Requiring them to become classes 
I'd say would be too harsh. That said, I agree that most of them 
would be a consume-and-throw-away (i.e. temporaries). But there's 
always an odd case where you'd want to consume them in staggered 
steps.