Hal Fulton wrote:
> Steve [RubyTalk] wrote:
>> This, I think is the crux of the matter.  It seems to me that given 
>> that if "aa".."b1" is a valid range, that calling calling succ on 
>> "aa" should logically eventually reach "b1".  I understand that in 
>> Ruby, today, it doesn't.
> I think that String#succ is of limited usefulness, and will *always* be a
> source of strange edge cases like this.
I can see circumstances where it might be useful to have a method 
defined as succ currently is (for example, maybe, when generating 
human-readable indices where character-encoding-order makes no sense.  
Ruby's notion of String, is far more powerful than that suggests - it 
allows an encoding of an arbitrary byte sequence - i.e. Ruby Strings 
(unlike strings in most languages) are appropriate type for manipulating 
binary "messages" - which is an _extremely_ useful feature (at least it 
is to me!)
> Personally, I think that (perhaps) String ranges should be disallowed as
> being mostly nonsensical (unless a rigid order, like character set order,
> were imposed).
I hope that they are not.  Obviously, the current mish-mash is far from 
desirable but  I, for one, will want to determine if a given binary byte 
sequence is "between" two other byte sequences.  The present situation 
is that I can do this using ranges if I replace succ with a "more 
sensible" (if likely less efficient) version to the default.  I wouldn't 
want to loose the support for byte-sequence ranges using strings - 
though I would be wholly in favour of any suggestion to rename succ 
"alpha_num_succ" (or similar) and to implement succ as iterating of byte 
sequence.  I can't see any reason that, by default, any standard type 
should not support a consistent total ordering... I hope that, in 
future, my wish might become reality. :-)

Steve