Front page | perl.perl5.porters |
Postings from January 2017
On 01/05/2017 08:56 PM, Aaron Crane wrote: > 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 +1.Thread Previous