Class/Interface Modeling of Ranges

[dsimcha]

== Quote from BCS (none at anon.com)'s article
> Hello dsimcha,
> > 3.  Can we simplify this by using runtime exceptions instead of
> > compile time errors for some of this stuff?  For example, every range
> > would have a hasLength() method and a length() method.  If hasLength()
> > is false, length() would throw.  Though this sacrifices compile time
> > error checking, it might be better in some ways.  For example, if a
> > given compile time type may or may not have length depending on its
> > runtime type, you could check at runtime whether it has a length and
> > adapt your handling of it accordingly.
> >
> make hasLength a static const variable and it can be used for reflection
> if you need polymorphism add a function that returns this.hasLength. Following
> that pattern, you could make much of the boiler plate into a mixin:
> template Range()
> {
>     bool p_hasLength() { return this.hasLength; }
>     int length() { static if(this.hasLength) return iLength() else thrown
> ... ; }
> }

Point of clarification, since I realized I omitted an important detail:  When I
said "every range has a hasLength() method", I meant every range that inherits
from the Range interface and is part of the class hierarchy.  This does **not**
apply to struct based ranges that only use compile time duck typing and are not
part of any class hierarchy.  These would be completely unaffected.