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

Petar Petar
Sat Jun 20 13:01:33 UTC 2020


On Saturday, 20 June 2020 at 12:30:43 UTC, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 11:20:13 UTC, Petar Kirov 
> [ZombineDev] wrote:
>
>> 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.
>
> Funny that, at the moment it's the copy ctors that aren't 
> working reliably (e.g. they're not working at all with arrays). 
> :)

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).

>> If it had worked, we could require that non-forward ranges are 
>> non-copyable.
>
> I can imagine this would be quite some work to adapt all of 
> Phobos to *that*. I mean, things like
>
> auto rem = makeSomeInputRange.find!pred;
> auto flt = makeSomeInputRange.filter!pred;
>
> Those would not compile. They could be made to compile by 
> `move`ing the argument for the return. But then you still won't 
> be able to pass those results around, unless via a refRange or 
> `move`.

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).


More information about the Digitalmars-d mailing list