develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
Dan Book
March 30, 2021 17:13
Re: on changing perl's behavior
Message ID:
On Tue, Mar 30, 2021 at 5:40 AM Christian Walde <>

> On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <
>> wrote:
> These second two futures are built with heavy investment in the difference
> between typing boilerplate and no boilerplate.  We already have a means to
> say "get the best Perl you can get," and it's something like:
> use v5.32.0; use warnings; use utf8; no feature 'switch';
> use if $USER eq 'rjbs',
>   experimental => qw(const_attr declared_refs refaliasing re_strict regex_sets signatures);
> Even that first line is a bunch.  Plausibly, it can all be boiled down to
> "use vX;" with a bit of doing.  Then we get into the space between
> boilerplate being "use vX" and being nothing.
> Another point here i want to see mentioned:
> I want future Perls to be as bold as possible. I want Perl v7 to change as
> much as it humanly can. I want it to be brutal, a sledge hammer. I want it
> to include every possible default change we can remotely justify. I want it
> to change so much as to get close to being a new language as the major
> version bump indicates.
> And these aren't thoughts i had on my own, they're condensations of
> thoughts others had that i agree with.
> However, without versioning it can't and in fact the existing proposed
> plans for unversioned default changes are extremely careful and
> conservative and in fact do very little at all. Not remotely enough to
> justify a major version bump. Maybe even to the point that it would be bad
> PR and in invitation of mockery if Perl bumped a major version with so few
> and small changes.
> These also are thoughts from others that i found myself agreeing with.
> Please give us a Perl dialect whose differences matter.

Co-signed. This is the overarching theme of my most recent post on the

Two particular examples for this point are the 'unicode_strings' and
'signatures' feature. Neither of these have a reasonable path to becoming
default, even if we wanted to, due to the impossibility of distinguishing
whether code was intended to run with or without these features; I don't
think anyone disagrees with this at the moment. But they are also two of
the most important features to provide a modern programming environment.

unicode_strings is more subtle than signatures, perhaps, but makes string
operations consistent rather than dependent on an internal string flag that
users don't and shouldn't interact with, and is one of many steps that can
provide a better unicode programming environment. It is also already
enabled in every feature bundle since v5.12. So promoting a "default"
programming environment without this feature is a step backwards. But
promoting and improving "use v7" brings this and many other great features
in for new code "for free".


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