Perl Steering Council

With Perl 5.36.0 just around the corner, we thought that this is a good time to clarify plans for the future of the Perl programming language. We realised that the future was hammered out in a number of steps, across several months. This meant that there hasn't been a single statement we could refer people to. This post is to fill that gap.

Two years ago Perl 7 was announced. A key idea for Perl 7 was to significantly reduce the boilerplate needed at the top of your code, by enabling a lot of widely used modules / pragmas, but this would have come at the price of breaking some backwards compatibility. This would have meant that some existing code wouldn't have worked without modification.

This prompted a lot of heated discussions: some thought this was a great idea, and some thought it a terrible idea to throw away one of Perl's key strengths. Ultimately this led to a discussion about who had the right to make this decision, now that Larry is no longer involved in Perl (and hasn't been for about 20 years). The end result of all those discussions was a new governance structure.

The Perl 5 Porters ("p5p") mailing list is still where the future of Perl is discussed, and we aim to build consensus, but where that's not possible, the three-person Perl Steering Council (PSC) has ultimate decision making authority on the future of Perl. The PSC is elected annually by the core team (the subset of p5p who have contributed most to Perl "recently"). The trigger for an election is the annual release of Perl, so the next election will happen after 5.36.0 is released.

The first PSC was elected in late 2020, and one of our first tasks was to create a plan for the future of Perl, and to put that in motion. A lot of discussion and iteration followed, but the strategy we agreed is:

1. Existing sensibly-written Perl 5 code should continue to run under future releases of Perl. Sometimes this won't be possible, for example if a security bug requires a change that breaks backward compatibility.
2. We want to drive the language forwards, increasing the rate at which new features are introduced. This resulted in the introduction of the RFC process, which anyone can use to propose language changes.
3. We want to make it easy for people to use these new features, and want to do what we can to encourage their adoption.

At the heart of this strategy are feature guards and version bundles.

Features

If a new language feature isn't backwards compatible, then it is protected with a feature guard. For example, Perl 5.010 introduced the say keyword. But it couldn't be enabled by default, as someone might have a say function in their code, which it would conflict with. So if you want to use say, you have to request it using the feature pragma:

    use feature 'say';
    say "hello, world";

Unguarded features

Not all new language features have a guard. If new syntax is introduced which would result in a syntax error in all previous versions of Perl, then it doesn't need a guard. For example, 5.36.0 introduces new syntax which lets you process N items at a time from a list:

    foreach my ($key, $value) (%hash) {
    …
    }

This new syntax doesn't have a feature guard, so it's available to use at line 0 (i.e. before you use v5.36).

Experimental features

Sometimes a feature will be marked as experimental, which means that we're not sure whether it's in the final form, and we'd like people to play with it and give feedback. The experimental status means that we reserve the right to change everything about it in a subsequent release, or even to remove it. If you use such a feature, you'll get a warning, which you can suppress with an extra line of code:

    use feature 'try';
    no warnings "experimental::try";

In general you shouldn't use experimental features in production code.

Version bundles

A lot of features have been added since 5.10.0, and a bunch more have been added in 5.36.0. That can mean that you end up putting a lot of use … lines at the top of all your code. Instead, you can enable all the stable (i.e. non-experimental) features provided in Perl 5.36.0 that weren't included in the original Perl 5 release, with just put this one line at the top of your code:

    use v5.36;

This does three things:

1. it tells the perl interpreter (and human readers), that your code requires perl 5.36.0 or later to run;
2. it enables all additional non-experimental features provided by Perl;
3. it uses a number of additional pragmas that have been accepted as good practice.

That one line is equivalent to:

    require v5.36;
    use strict;
    use warnings;
    use feature 'say';
    use feature 'state';
    use feature 'current_sub';
    use feature 'fc';
    use feature 'lexical_subs';
    use feature 'signatures';
    use feature 'isa';
    use feature 'bareword_filehandles';
    use feature 'bitwise';
    use feature 'evalbytes';
    use feature 'postderef_qq';
    use feature 'unicode_eval';
    use feature 'unicode_strings';
    no feature 'indirect';
    no feature 'multidimensional';

Code that starts with use v5.36 will run against future versions of Perl – all versions of Perl know about the version bundles of previous versions of Perl.

Version bundles have two main benefits:

• they greatly reduce the boilerplate you have to write at the top of your code, and
• they document what version of Perl your code was written to. Version bundles have been supported since 5.10.0, but not widely understood or used. With the release of 5.36 we hope to change that.

We have a lot more proposals in the pipeline, including the introduction of richer OO syntax. We expect 5.38 to include another swathe of new features.

What about Perl 7?

For now, our plan is to continue introducing new features and to resolve all existing experimental features, so they're either dropped, or become non-experimental features (and so are included in the version bundle).

The downside with this is that people often can't remember which version of Perl introduced which feature(s).

At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0.

If this happens, Perl 7 will still be backwards compatible with Perl 5 by default – you'll have to put use v7; at the top of your code to use all the new features.

Think of use v7 like Modern::Perl and similar modules.

Annual releases would continue, so it would then be followed by 7.2, 7.4, etc. We have a lot of good ideas in the works, and if we can keep up the momentum of the last year, then things look promising. And in the meantime we'll continue with 5.XX releases.

Why not Perl 7 instead of 5.36?

Some people, hoping to see Perl 7 sooner rather than later, have asked, "Why wasn't this latest release of Perl released as Perl 7? It's got a bunch of new stuff, after all!" The answer to this question depends on who you ask, but for the PSC, we can agree on something like this:

Changing the version number can serve two jobs. One is to indicate to a potential upgrader that there may be backward incompatibilities. We have generally decided against doing this, rejecting the original Perl 7 plan. The other job is to alert casual observers that the new release is a significant milestone, and that folks who wouldn't otherwise give much thought to the upgrade should take this time to re-evaluate the tool's fitness. That's the value we imagine getting out of a "Perl 7" release: it tells people to come look, because they might realize they'd like to start doing some more work in Perl.

This is not a tactic we'd like to invoke lightly. If we announce "Perl 7! A whole new Perl!" and the upgrades are modest and not likely to sway anybody who isn't already keen, it doesn't only fail, but also sours the tactic for next time. A future Perl 8 will be viewed as likely to be another modest upgrade. We want to reserve the big bump for changes that we think will reward people who take the time to look into it. Perl 7 can't be crying wolf.