Zoffix Znet via RT wrote:
>Thanks for the report, however, there's no bug here, as strings are valid
>version parts, which is what the diaeresis causes the part to parse as
>(as opposed to numbers).
I'm aware that non-numeric parts are permitted, but the behaviour here
doesn't seem to be consistent in treating that character as non-numeric.
It's treating the whole "34\x[308]5" string as a single string part.
This is unlike the behaviour with an alphabetic character (splitting the
string into three parts), a non-ASCII digit without diacritics (taken as a
digit making a single numeric part), or an arbitrary punctuation character
(taken as a separator splitting the string into two numeric parts):
> Version.new("34\x[308]5").parts.perl
("34?5",)
> Version.new("3z5").parts.perl
(3, "z", 5)
> Version.new("3\x[664]5").parts.perl
(345,)
> Version.new("3!5").parts.perl
(3, 5)
I would expect the digit with diacritic to behave like one of those
other cases. Instead it is in a category of its own. Further bizarre
behaviour is seen when mixing the digit-with-diacritic with letters:
> Version.new("34\x[308]5z7").parts.perl
("34?5", "z", 7)
> Version.new("3z56\x[308]7").parts.perl
(3, "z", "56?7")
> Version.new("3z6\x[308]p").parts.perl
(3, "z", "6?", "p")
The behaviour seems to be a mixture of digit and letter behaviour:
it behaves as a digit for the purposes of grouping characters into
digit parts and letter parts, but then behaves as a non-digit for the
purposes of determining which kind of part it appears in (forcing it to
be a string part rather than numeric).
If it's really intended to have this unique behaviour, incorporating
adjacent digits into a string part, then that needs to be documented.
There's no mention of it at present. I think more likely it was not
intended to be a unique category, and by accident has picked up a mixture
of the behaviours of intentional categories.
Point taken about me having used the wrong comparison operator.
-zefram
