Problem with using struct ranges with @disabled this(this) with some range functions

Uranuz via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Sep 2 00:52:56 PDT 2015


On Wednesday, 2 September 2015 at 07:34:15 UTC, Mike Parker wrote:
> 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?

I want to understand if we have *save* method in Forward Range 
then why or in which cases we should use plain struct copying 
instead. Should we assume that these two ways are equal or not?

Also as far as I understand behaviour for Input Ranges vs Forward 
Ranges would be different, because you could not store cursor on 
object like network data stream, because as soon as you read from 
it you cannot save some range that will point on previous bytes 
in network stream, because they are gone if you read them.

So for Input Range copy will always point on current state, but 
not previois state, that was saved before in another range 
pointing to the same source.

For Forward Range we have ability to save cursor position and 
return to it later. In this case would copying via postblit would 
be equal to *save* method or would be similar as for Input Range.


More information about the Digitalmars-d-learn mailing list