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...
