Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
From: Dan Book
June 26, 2020 05:01
Re: Announcing Perl 7
Message ID: CABMkAVVZi3qGm3UnD0g60=UWt=BXmQQ+2Po+GivCWtsvQYn64w@mail.gmail.com
On Fri, Jun 26, 2020 at 12:24 AM Karl Williamson <email@example.com>
> I don't understand many of the objections. No one is going to force
> people to move off 5.32, and we are promising a 5-10 year support
> window. I think that is ample.
This is unrelated. The objections, at least from my point of view, is the
combination of three factors. Making the new version incompatible breaks
most of CPAN, it will be a huge amount of effort to make it even usable.
Making it incompatible doesn't actually solve most of the issues raised as
motivation for this change. And there are plenty of things that can be done
without making incompatible changes, which simply require someone to do
them. In summary, the concern is that this is introducing unnecessary
breakage that won't solve the problems at hand, especially those it's
purported to help (which I would very much like to help).
> I also need some examples as to why unicode_strings is problematic. The
> dodgy behavior it fixes can't be what is intended going forward. Maybe
> the default becomes it goes on, and you can turn it off for binary-like
> data with a renamed 'use bytes'.
This would need to be a specific concern of the distribution that runs into
issues. All unicode_strings does is make certain specific string operations
act consistently regardless of whether Perl decided to store a string in
the upgraded or downgraded storage format; without the feature, these
operations use ascii rules on downgraded strings and unicode rules on
upgraded strings, which is noticeable when the string may have non-ascii
characters that can be represented in the downgraded format (such as é). It
does not require any change to how the contents of strings are used; at
worst it requires rethinking regexes that may be affected by unicode rules.
use bytes is not related, since it causes completely different broken
behavior of using the underlying storage format directly in Perl; you turn
it off to go back to the default heuristic by disabling the unicode_strings