develooper Front page | perl.perl5.porters | Postings from January 2017

Re: Does the range operator still have the Unicode Bug?

Thread Previous | Thread Next
Aaron Crane
January 5, 2017 19:56
Re: Does the range operator still have the Unicode Bug?
Message ID:
Aaron Crane <> wrote:
> I'd considered editing perlop, but couldn't find a way to
> describe the change that didn't involve spending a lot of words
> describing behaviour that I consider extremely confusing. The existing
> perlop documentation is completely correct for the fixed behaviour, in
> that it describes ".." in terms of string length and magical
> increment.

After further thought, I've come up with the following addition to
perlop, and squashed it into the smoke-me/arc/unicode-range-operator
diff --git a/pod/perlop.pod b/pod/perlop.pod
index 2640b5173d..82dca55d52 100644
--- a/pod/perlop.pod
+++ b/pod/perlop.pod
@@ -1074,6 +1074,12 @@ If the final value specified is not in the
sequence that the magical
 increment would produce, the sequence goes until the next value would
 be longer than the final value specified.

+As of Perl 5.26, the list-context range operator on strings works as expected
+in the scope of L<< S<C<"use feature 'unicode_strings">>|feature/The
+'unicode_strings' feature >>. In previous versions, and outside the scope of
+that feature, it exhibits L<perlunicode/The "Unicode Bug">: its behavior
+depends on the internal encoding of the range endpoint.
 If the initial value specified isn't part of a magical increment
 sequence (that is, a non-empty string matching C</^[a-zA-Z]*[0-9]*\z/>),
 only the initial value will be returned.  So the following will only

Aaron Crane **

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About