On Wednesday, 2 September 2015 at 06:28:52 UTC, Uranuz wrote:
As far as I understand to save current cursor of forward range
I should always use *save* property. But sometimes range struct
is just copied using postblit without using save (it happens
even in Phobos). Is it correct behaviour to *pass ownership*
for range structs via just copying of range or not. As I think
for at least *forward* ranges that are structs we must always
use save methot to store new cursor. But for *input* ranges it
is not possible, so there maybe plain copying could be allowed.
I thing that we should work out some descision on this problem,
provide some unittests for different types of ranges with and
without postblit for standard Phobos functions and fix them
accordingly.
I have problem with std.range.take function and forward range
with disabled postblit and I don't understand is it my or
library bug?
My understanding is that one underlying assumption in Phobos
about ranges is that they are lightweight and single-minded --
they should carry no state other than what is necessary to
fulfill the range interface they provide. This follows from the
idea that, given a container, you do not slap a range interface
on the container type and pass container instances to range-based
functions, but instead implement a range type separate from the
container that knows where the elements of the container begin
and end and nothing else. They do not carry the elements of the
container around with them.
Looking at ranges from that angle, the need to disable postblit
on a range type would be a special case. That raises the
question, for what reason have you disabled postblit on your
range type? Is it not possible for you to create a lightweight
range from your data?
