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