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