develooper Front page | perl.perl5.porters | Postings from October 2016

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

Thread Previous | Thread Next
Karl Williamson
October 31, 2016 19:45
Re: Does the range operator still have the Unicode Bug?
Message ID:
On 10/31/2016 11:50 AM, Sawyer X wrote:
> On 10/30/2016 07:10 PM, Aristotle Pagaltzis wrote:
>> * Sawyer X <> [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
>   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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About