Issue with forward ranges which are reference types

Steven Schveighoffer schveiguy at yahoo.com
Wed Aug 17 11:15:52 PDT 2011


On Wed, 17 Aug 2011 13:15:27 -0400, Lars T. Kyllingstad  
<public at kyllingen.nospamnet> wrote:

> On Wed, 17 Aug 2011 10:19:31 -0400, Steven Schveighoffer wrote:
>
>> On Wed, 17 Aug 2011 00:05:54 -0400, Jonathan M Davis
>> <jmdavisProg at gmx.com> wrote:
>>
>>> So, the question is, should a range-based function have the same
>>> behavior for
>>> all forward ranges regardless of whether they're value types or
>>> reference types? Or should the caller be aware of whether a range is a
>>> value type or a
>>> reference type and call save if necessary? Or should the caller just
>>> always
>>> call save when passing a forward range to a function?
>>>
>>>
>> Probably not helpful, since the establishment seems to be set in their
>> opinions, but I'd recommend saying ranges are always structs, and get
>> rid of the save concept, replacing it with an enum solution.  The
>> current save regime is a fallacy, because it's not enforced.  It's as
>> bad as c++ const.
>>
>> At the very least, let's wait until someone actually comes up with a
>> valid use case for reference-based forward ranges before changing any
>> code.  So far, all I've seen is boilerplate *RangeObject, no real
>> usages.
>
> As long as most functions in std.algorithm don't take the ranges as ref
> arguments, you need to use a reference-based range whenever you want the
> function to consume the original range.
>
> BTW, this is why I suggested earlier that we add a byRef range.  If you
> absolutely want the function foo() to consume your range, write
>
>    foo(byRef(myRange));

Do you have a real example besides foo which makes sense on both byRef and  
by value ranges?

I think it's rather important for the function implementation to know  
what's happening with its range while using it.

-Steve


More information about the Digitalmars-d mailing list