develooper Front page | perl.perl5.porters | Postings from June 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
Sawyer X
June 26, 2020 19:42
Re: Announcing Perl 7
Message ID:
On Thu, Jun 25, 2020 at 11:16 AM Dave Mitchell <> wrote:
> On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
> > * Major versions will be used for two purposes: 1. Turn on features
> > and pragmas by default, 2. Remove syntax from the language.
> I want to be on the record that I extremely strongly oppose this change.


I'm sorry you feel this way, but I hope to turn this around, or at
least to change that your vehement disagreement will be accompanied by
understanding why this decision was made.

I have given very brief responses below, but at the bottom, I go at
more length on what I think is the main topic you object to. It
doesn't cover everything in email, but it's not easy for me to address
everything you wrote in one go, so please bear with me.

> I think if people want to use the new modern perl, they just put this
> one simple line at the top of their code:
>     use v7;

This cannot achieve what we want. I don't believe it even achieves
what you suggest. As explained below, "use v" is not practically

> this makes everything forward and backwards compatible, and eases the
> transition. The thing is that old perl binaries back to at least 5.8.x
> recognise this syntax and will produce a helpful error message:
>     $ perl589 -e'use v7'
>     Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1.

We are not removing "use v" but we are recognizing that it doesn't
provide what we need. I would venture that while you can still use
"use v", you probably don't want it anyway, even in 5.32.0. I know I
couldn't use it in any code I have, whether professionally or on CPAN.

> this helps everyone: writers of perl7 code will know what the problem
> is when they accidentally run their code on an old perl binary, rather
> than getting some obscure error message.
> Older code continues to run without modification - you don't
> have edit every source file to add a 'use compat::perl5' line.
> You don't have to update every existing perl installation to add the
> compat::perl5 module just so that existing code will continue to run.
> CPAN continues to work.

If you have numerous files, they each have to have "use v".

Your proposal doesn't change the fact that a use statement needs to be
added by someone. You suggest that this particular someone not be
those keep their code static, but those who want to actively write
code. That's a fair position, but it's only another coin of the plan's
argument. You say "New users add 'use v'" and I say "Old users update
or add 'use compat::perl5'". The same idea of adding lines of code,
just the question is who.

> 'use v7' also allows the new stuff to be scoped to a single source file;
> other .pm files can still be included unmodified using the old perl
> syntax.

That's actually far worse and is a major reason "use v" is not suitable.

> Look, we've got this great built-in mechanism, 'use vx.y.z' that's been
> around forever. It hasn't seen much use yet, because frankly there's
> been very little call for it, since there hasn't been much new
> non-backcompat stuff so far. But its been sitting there waiting for use to
> use it.

This mechanism isn't in use because it does not work.

> In 5 years or whatever, it will also save our bacon when perl8 is
> released; suddenly all that source code with 'use v7;' at the top will
> continue to work on the perl8 interpreter running in perl7 mode. Rather
> than suddenly all breaking.

This isn't the scenario. It's the scenario you are painting in the
email. Why would all code suddenly break when we release version 8?

> It helps IDEs as well - now they can look at a source file and know
> instantly what major release of perl this file was written against, and
> so how to syntax highlight etc.

Are you suggesting that IDEs create different parsers for the Perl
syntax based on pragmas turned on in scopes? Can you give an example
of an IDE that does this now?

> [...]

I'm cutting the rest because it is both too long and includes several
points raised which makes it difficult to respond to each section
separately at length in one email.

Instead, I will focus on one particular aspect: "use v" does not work for us.

1. People do not actually use "use v". This is what we've seen with it
so far. CPAN is an example, and every code-base I touched and
discussed with peers had rarely used it. It is true that this is
anecdotal because I haven't touched or discussed every code-base, but
I am in touch with a few major Perl shops. It is rarely used by any of
them. This has to account for a fair portion of active Perl code and
this anecdote does means something. We have a mechanism we believe is
superior and gives our users what we think we want. Our users don't
use it. Aergo, our mechanism isn't the gift to developers we thought
it is.

2. "use v" turns on *everything* till this version. With 7.0, we do
not intend to turn on everything. If you were to take a large
code-base, you will not be able to easily transition it to
*everything* in It's impossible, even with an exhaustive
set of tests, because the number of changes, both to syntax and
semantics, will require a lot of updating and probably tests you
haven't even thought of. A good example is unicode_strings. If I had
written 10K lines assuming my strings are bytes, I'm screwed. Will I
get the time to actually go ahead and change all of my code to assume
otherwise? Probably not. For 7.0, we will turn on very few pragmas and
features, to allow people to make a relatively seamless update. This
is already being tested with a few stakeholders and is proving fairly

3. "use v" being lexically scoped is even worse in this respect.
Different code within the same code-base that touches the same data (a
fairly common occurrence) will now have some lines of code that assume
the string is bytes and some assume it is Unicode characters. This
makes the code nearly impossible to work with. If in #2, I expressed I
can't move a large code-base to every possible feature and pragma at
once, the fact that it's lexical can only make it worse for me because
I don't know if a line of code that has it enabled will trigger a line
of code in a different package which doesn't have it enabled.

4. "use v" is meant to make "use feature" easier. Using
indefinitely makes it impossible to ever remove code, which is also
something we are actively trying to change. This means that "use v"
does even more to cement feature guards' infinite existence. Why
remove crufty features in the code when we can just keep it on by
default and force all developers to indicate they don't want it?

An example of this situation is as follows:

  package Foo {
    use feature qw< unicode_strings >;
    sub match { print $_[0] =~ /ss/i ? "Foo: match\n" : "Foo: no match\n" }
    sub match_with_bar { Bar::match(@_) }

  package Bar {
    sub match { print $_[0] =~ /ss/i ? "Bar: match\n" : "Bar: no match\n" }

  my $x = "\xDF";
  Foo::match($x); # works
  Foo::match_with_bar($x); # doesn't work

To summarize:

* With "use v" I need to add this *everywhere*.
* With "use v" I need to deal with even significantly breaking changes
and I need to deal with all of them at once. (Like within a
single-but-large file.)
* With "use v" I need to add this to all files and deal with all of it
at once because due to it being in a package scope, it can create a
vast action-at-a-distance behavior. I could trigger code within my
code-base which wasn't updated or code in a module which wasn't
* With "use v" the code will not get removed, which is the opposite of
what we want

"use v" is effectively a non-starter. It doesn't allow people to
progressively update their code, only gives them an all-or-nothing
"solution." That's not a real solution. As much as it doesn't help
them, it doesn't allow us to remove any code, ever.

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