On Sun, 26 Dec 2010 00:36:26 +0000 (UTC) Tomek Sowiński <j...@ask.me> wrote:
> > <proposed> > > > > A random-access range is a bidirectional range OR an infinite forward > > range that offers the primitive opIndex. > > > > </proposed> > > > > I can't be sure whether the former should also provide the primitive > > 'length'. > > I think so. If you got random access and know the end, you should also > know how far is the end element. At least I can't think of a counter > example. Same for me. And that's why I think '$' should map to a length attribute or property, and not to a not-yet-implemented opDollar. Make 'length partially magic for that case. Simpler, and would work in 90% cases, since 'length' is the _de facto_ conventional D name. > > That would make sense, but having the hasLength helper makes it also > > feel like 'length' is an optional property of ranges. > > Length in general is an optional feature of ranges. > > Taking a look back, I wonder if the notion RandomAccessRange is useful > at all. Where elements are accessed randomly (e.g. sorting, viewing), > one doesn't really need the thing to be a range. That suggests a loose > feature rather than a place in hierarchy. Was hasRandomAccess and > hasSafeRandomAccess considered? (the latter has random access and > (length (x)or infinity)) I agree. Or, conversely, make structs/classes that implement random-access (opIndom+length) be automatically considered as input/forwar/bidi without having to overload with 6 additional methods. Anyway, rewriting the loops may be different for such random-access ranges. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
