Michael Zedeler wrote: > Proposed changes: > > It shouldn't be possible to construct RangeIterators over Str (apart from > single length strings) or Complex using the Range operator (..).
I'd go one step further with Complex, to say that Range isn't a useful concept at all so long as "before" and "after" are undefined. As for Str, I'm not sure that we should go so far as to say that you _can't_ create RangeIterators over them, so much as to say that the default step algorithm is defined only for single-character strings, and fails if you give it anything else. In particular, the programmer should be allowed to enable Str-based RangeIterators by explicitly supplying his own step algorithm. That is: 'aa' .. 'zz' # Error in list context: default stepper rejects multi-character endpoints 'aa' .. 'zz' :by(&stepper) # custom stepper overrides default concerns > Next open question: > > What about Ranges using different types in each endpoint? > > 1.5 .. 10 :by(0.5) > (Rat .. Int) > > "0" .. 7 > > Should they be coerced - and in that case to what? If we don't coerce them, > what should be returned? This is only a half-formed thought at the moment, so please bear with me: maybe Ranges should extend the triptych that exists with comparison operators. That is, you have "before" and "after", "lt" and "gt", and "<" and ">"; you also have "cmp", "leg", and "<=>". Perhaps ".." should be treated as the numeric operator, and equivalent Str and generic operators should be supplied separately. I'd be inclined to spell the generic Range operator - the one corresponding to "before"/"after"/"cmp" - as "to". I'm not sure how the Str-based one ought to be spelled. With "..", there should be automatic coercion of both endpoints to numbers, just as there is with "<" and ">". With "to", there should be no coercion at all, just like "before" "after", and "cmp". -- Jonathan "Dataweaver" Lang
