Jon Lang wrote:
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.
Agreed. I should have written that as part of the proposal as well.
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
The difference between this and the triple dot-operator is that we
provide an upper bound (and are forced to use the :by-adverb). Is it
worth the while?
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".
And just like .. should nummify, the to operator should stringify?
Sounds nice.
Regards,
Michael.
