Issue with forward ranges which are reference types

Mehrdad wfunction at hotmail.com
Tue Aug 16 23:20:14 PDT 2011


On 8/16/2011 9:37 PM, Jesse Phillips wrote:
> On Tue, 16 Aug 2011 21:17:31 -0700, Mehrdad wrote:
>
>> On 8/16/2011 9:05 PM, Jonathan M Davis wrote:
>>> Sorry that this is long, but it's very important IMHO, and I don't know
>>> how to make it much shorter and cover what it's supposed to cover.
>>>
>>> Okay. Your typical forward range is either an array a struct which is a
>>> value type (that is, copying it creates an independent range which
>>> points to the same elements and is not altered if the original range is
>>> altered - the elements that it points to aren't copied of
>>> course).<snip>  Thoughts?
>>>
>>> - Jonathan M Davis
>> Funny, I was also thinking about this recently.
>>
>> The trouble is that that's not the only issue. There's also the issue
>> with polymorphism -- i.e., InputRangeObject is pretty much *useless*
>> right now because no function ever checks for it (AFAIK... am I wrong?).
>> So if you pass a random-access range object as an InputRange, the callee
>> will just assume it's an InputRange and would reject it. So you're
>> forced to downcast every time, which is really tedious. Things don't
>> "just work" anymore.
> All of the range functions check for functionality, so if your random-
> access range object contains, popFront, front, empty (which it is
> required to to be random-access range) then it will be accepted as an
> InputRange.
Right, but the problem is that none of this template business (e.g. 
isInputRange!T, hasLength!T, etc.) works if the input is an Object that 
implements InputRange.

For example, consider this:

     static Object getItems()
     { return inputRangeObject([1, 2]); }

     Object collection = getItems();
     if (collection.empty)  //Whoops...
     {
         ...
     }

The caller has no idea what kind of range is returned by getItems(), but 
he still needs to be able to check whether it's empty.

How can he figure this out? He would be forced to cast (which is by 
itself a pretty bad option), but what can he cast the object to?  
InputRange!Object doesn't work because it could be an InputRange!string 
or something. There's really NO way (that I know of) for the caller to 
test and see if the collection is an input range, unless he knows the 
type -- which runs counter to what I've seen in other OOP languages (C#, 
Java).

Hope that makes sense...


More information about the Digitalmars-d mailing list