Front page | perl.perl5.porters |
Postings from October 2016
Re: Does the range operator still have the Unicode Bug?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
October 31, 2016 17:50
Subject:
Re: Does the range operator still have the Unicode Bug?
Message ID:
71ff8a14-535c-18c5-4a70-b1b66b19c74d@gmail.com
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.
> 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