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. Considering your work I'm sure you know this so I'm probably misunderstanding what point your are making?
