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

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

Thread Previous
Sawyer X
January 6, 2017 09:37
Re: Does the range operator still have the Unicode Bug?
Message ID:

On 01/05/2017 08:56 PM, Aaron Crane wrote:
> 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
> 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


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