I ran into a situation where I needed a forward range which was not a reference type to be consumed by a range-based function. Input ranges and reference type forward ranges are automatically and unavoidably consumed by range-based functions (assuming that save isn't called on them before the function starts consuming them), but that doesn't happen for either value type ranges or arrays. Hence my wrapper type (called RefRange). The code is here:

http://codepad.org/nNB4mAdN

I was wondering what other people's take on it was and whether I missed something which makes it a bad idea. Essentially, it's a range with a pointer to the original range so that any function calls on the wrapper affect the original range (and vice versa).

Assuming that no one pokes a major hole in it, and others think that it's a worthwhile addition, I'll create a pull request for it to be added to std.range. But I'd like other people's feedback on it first.

- Jonathan M Davis

On Thursday, 14 June 2012 at 04:14:02 UTC, Jonathan M Davis wrote:
> I ran into a situation where I needed a forward range which was not a
> reference type to be consumed by a range-based function. Input ranges and
> reference type forward ranges are automatically and unavoidably consumed by
> range-based functions (assuming that save isn't called on them before the
> function starts consuming them), but that doesn't happen for either value type
> ranges or arrays. Hence my wrapper type (called RefRange). The code is here:
>
> http://codepad.org/nNB4mAdN
>
> I was wondering what other people's take on it was and whether I missed
> something which makes it a bad idea. Essentially, it's a range with a pointer
> to the original range so that any function calls on the wrapper affect the
> original range (and vice versa).
>
> Assuming that no one pokes a major hole in it, and others think that it's a
> worthwhile addition, I'll create a pull request for it to be added to
> std.range. But I'd like other people's feedback on it first.

It is definitely a good idea.  Basically, it provides the opposite guarantee of save().  If you're going to use the range once and then throw it away, and therefore don't care whether it is consumed or not, just use it directly.  If you want to ensure it does not get consumed, use a copy obtained through save().  If you want to ensure it *does* get consumed, use a reference to it.

However, someone pointed out here earlier that, since D uses the dot operator for pointer dereferencing, a pointer to a range is also a range.  It just isn't recognised as such by foreach.  So if we could just fix foreach, and maybe add functions providing range primitives for T[]* to std.array, I don't think we need a separate RefRange.  Just take the address of the range when you want to ensure it gets consumed.

-Lars

On Thursday, June 14, 2012 07:35:35 Lars T. Kyllingstad wrote:
> On Thursday, 14 June 2012 at 04:14:02 UTC, Jonathan M Davis wrote:
> > I ran into a situation where I needed a forward range which was
> > not a
> > reference type to be consumed by a range-based function. Input
> > ranges and
> > reference type forward ranges are automatically and unavoidably
> > consumed by
> > range-based functions (assuming that save isn't called on them
> > before the
> > function starts consuming them), but that doesn't happen for
> > either value type
> > ranges or arrays. Hence my wrapper type (called RefRange). The
> > code is here:
> > 
> > http://codepad.org/nNB4mAdN
> > 
> > I was wondering what other people's take on it was and whether
> > I missed
> > something which makes it a bad idea. Essentially, it's a range
> > with a pointer
> > to the original range so that any function calls on the wrapper
> > affect the
> > original range (and vice versa).
> > 
> > Assuming that no one pokes a major hole in it, and others think
> > that it's a
> > worthwhile addition, I'll create a pull request for it to be
> > added to
> > std.range. But I'd like other people's feedback on it first.
> 
> It is definitely a good idea.  Basically, it provides the opposite guarantee of save().  If you're going to use the range once and then throw it away, and therefore don't care whether it is consumed or not, just use it directly.  If you want to ensure it does not get consumed, use a copy obtained through save().  If you want to ensure it *does* get consumed, use a reference to it.
> 
> However, someone pointed out here earlier that, since D uses the dot operator for pointer dereferencing, a pointer to a range is also a range.  It just isn't recognised as such by foreach.  So if we could just fix foreach, and maybe add functions providing range primitives for T[]* to std.array, I don't think we need a separate RefRange.  Just take the address of the range when you want to ensure it gets consumed.

I don't think that that would work with save or opSlice though. Granted, save and opSlice _can_ make it so that the range isn't consumed like you'd like, depending on how the function that you're passing it to is implemented, but having RefRange implement save and opSlice is still useful, and is actually necessary if you want it to work as RandomAccessRange and the like (since all of the more complex ranges are forward ranges). So, if that won't work with a pointer (and I don't think that it will, since the type would be completely wrong), then you'd still need a type like RefRange.

- Jonathan M Davis

On Thursday, 14 June 2012 at 05:45:50 UTC, Jonathan M Davis wrote:
> On Thursday, June 14, 2012 07:35:35 Lars T. Kyllingstad wrote:
>> However, someone pointed out here earlier that, since D uses the
>> dot operator for pointer dereferencing, a pointer to a range is
>> also a range.  It just isn't recognised as such by foreach.  So
>> if we could just fix foreach, and maybe add functions providing
>> range primitives for T[]* to std.array, I don't think we need a
>> separate RefRange.  Just take the address of the range when you
>> want to ensure it gets consumed.
>
> I don't think that that would work with save or opSlice though. Granted, save
> and opSlice _can_ make it so that the range isn't consumed like you'd like,
> depending on how the function that you're passing it to is implemented, but
> having RefRange implement save and opSlice is still useful, and is actually
> necessary if you want it to work as RandomAccessRange and the like (since all
> of the more complex ranges are forward ranges). So, if that won't work with a
> pointer (and I don't think that it will, since the type would be completely
> wrong), then you'd still need a type like RefRange.

Ah, that's true, of course.  Indexing and slicing would be a disaster if one tried to do it with a pointer to a range. :)  Then we should definitely have a RefRange.  I actually suggested the very same thing on the Phobos ML myself once, but Andrei argued it would be better to define a more general Ref type, which works with all kinds of types, and not just ranges.  Personally, I would be happy with something just for ranges.

-Lars