Front page | perl.perl5.porters |
Postings from October 2016
Re: Does the range operator still have the Unicode Bug?
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
October 31, 2016 19:45
Subject:
Re: Does the range operator still have the Unicode Bug?
Message ID:
ead5dca9-be1e-80de-0ac3-319c656d1615@khwilliamson.com
On 10/31/2016 11:50 AM, Sawyer X wrote:
>
>
> On 10/30/2016 07:10 PM, Aristotle Pagaltzis wrote:
>> * Sawyer X <xsawyerx@gmail.com> [2016-10-30 12:36]:
>>> There were improvements here made in 5.12, 5.14, and 5.16. This means
>>> that there weren't deprecation cycles here. However, as you say, we're
>>> not at 5.18, but much further ahead, meaning at this point people
>>> possibly already use this. This does require additional
>>> considerations. I'm wondering if we could make the change sooner to
>>> "unicode_strings" (as it purports to handle these) with no warning.
>> I don’t understand what that solves. The `unicode_string` feature gets
>> enabled by `use 5.012`, meaning lots of code would get the change with
>> no grace period of any kind. This falls under “do we want people to be
>> able to upgrade their perl without fear of breakage?”
>
> I understand you're saying we should consider it a breakage issue. I
> have already agree with it in principle. We're discussing now what it
> actually means with how to solve it.
>
> The reason I suggested the feature pragma here (and it can very well be
> misguided, which is why I asked) is that there's some understanding by
> explicitly enabling something which states to try and take care of much
> of as possible.
>
> Here is the except of "unicode_strings" from feature.pm:
>
> The 'unicode_strings' feature
> "use feature 'unicode_strings'" tells the compiler to use Unicode
> rules in
> all string operations executed within its scope (unless they are also
> within the scope of either "use locale" or "use bytes").
>
> This purports to "fixing it", not to only doing so in the places we know
> about (that's implied). One can determine clearly by this document, that
> when you enable "unicode_strings", you explicitly want it fixed, because
> that's what it declares it doesn't. It doesn't say "I will alter *THIS*
> statement", but "all string operations". If we found one that fails, we
> can claim it needs to be added, since it already falls into that definition.
>
>> If you want a repeat of the 5.12 strategy, you would have to add a new
>> feature for this change.
>
> What do you mean by "5.12 strategy"?
>
> The section I quoted continued in the next paragraph with:
>
>
> This feature is available starting with Perl 5.12; was almost fully
> implemented in Perl 5.14; and extended in Perl 5.16 to cover
> "quotemeta".
>
> This indicates that there are behavioral changes in this pragma twice in
> the next two consecutive versions. They didn't reach require two
> additional releases.
>
> To phrase differently, if I understand it correctly, the thought process
> was "let's add it (5.12)", then "oh wait, we have more changes (5.14)",
> and "ugh, also quotemeta! (5.16)". Meaning, "let's add this fix to the
> next version". That seemed like the strategy in 5.14 and 5.16 which
> makes sense to me, considering it's a feature and - again - what it
> purports to doing. I Don't know what the "5.12 strategy" was, other than
> fixing it.
>
This is essentially correct, although we knew in 5.12 that this was a
partial implementation, with more to come later. The quotemeta issue
had been overlooked, and was added in 5.16, without any user complaint
about breakage.
>
>> But using the feature mechanism in any way for this would mean having to
>> preserve both code paths going forward: it makes the codebase worse, not
>> better.
>
> Why would it mean that?
>
>
>> I would prefer to see this just fixed, for everyone, with cleaner code.
>> And it’s very *likely* that that can be done… just not *known*. A cycle
>> or two with warnings would give us data to calibrate the guess.
>
> Again, I'm not necessarily against that. I'm trying to add more
> considerations here. Perhaps the feature is the right place for it,
> using "unicode_strings".
>
Thread Previous
|
Thread Next