Front page | perl.perl5.porters |
Postings from January 2017
Aaron Crane <arc@cpan.org> 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 branch: 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 ** http://aaroncrane.co.uk/Thread Previous | Thread Next