Perl 7 proposes a new contract for default behavior

Perl can acquire a new facility without making that facility the default for existing programs. Its feature pragmas preserve that distinction, but they also require each new program to select behavior that its author may regard as ordinary practice. Sawyer X's Perl 7 announcement proposes changing how that burden is distributed. A new major version would start with different defaults while retaining substantially the Perl 5.32 implementation.

The June 24 announcement on Perl.com describes the plan following Sawyer's talk at The Perl Conference in the Cloud. His message to perl5-porters that day gives a more precise account of the intended version policy and the work still outstanding. The distinction matters because this is an announced plan, not a released Perl 7 interpreter. Decisions about individual defaults remain part of the work.

The engineering question is whether a major-version boundary can make starting a Perl program simpler without forcing every older program to change at once. Compatibility provisions are therefore part of the proposal's substance. They determine whether changing the initial settings is a manageable interpreter upgrade or an application migration that cannot be separated from deployment.

Feature pragmas already separate capability from defaults

The feature pragma shipped in Perl 5.32 explains why adding syntax is difficult. A new construct can conflict with an existing program's interpretation. The pragma permits new syntax or semantics only within a lexical scope that enables the relevant feature. That allows the implementation to add behavior without immediately assigning it to every source file it compiles.

Lexical scope is important here. A declaration changes the enclosing block from that point onward. A nested block can disable a feature, while surrounding code retains its previous setting. This provides local control within a program, instead of requiring every source unit using an interpreter to share one language configuration. The same documentation describes version bundles that select a collection of features together.

Requiring a minimum version through use VERSION implicitly loads the matching bundle. Starting with a sufficiently recent version declaration also enables strictures. The reference specifically distinguishes use v5.12 from merely selecting its feature bundle, because the version declaration includes the equivalent of use strict. These mechanisms already give authors a way to request a more recent language environment explicitly.

use v5.32;
use warnings;
no feature 'indirect';

This is valid Perl 5.32 configuration. It shows that the current interpreter can already select some behavior discussed in the Perl 7 plan. It does not emulate a finalized Perl 7 configuration, because that configuration has not yet been selected. Keeping the example within the released implementation avoids presenting proposed interfaces as installed facilities.

I value Perl's directness for one-off text work. Repeating language setup before a small transformation can be disproportionate to the operation itself. Sensible initial settings are therefore a useful design goal, provided the compatibility mechanism remains understandable to someone reading an older program.

A major version would select defaults for its whole series

Sawyer proposes two uses for major versions. They would enable features and pragmas by default, and they would permit syntax removal. New facilities added during a major series would remain guarded by use feature. A subsequent major version would then enable them by default. The plan therefore retains explicit opt-in during a series while creating a named opportunity to revise its starting configuration.

That is more specific than saying every new feature becomes available immediately everywhere. It gives a source file's initial interpretation a relationship to the interpreter's major version. The existing lexical controls remain relevant within that environment. The proposed boundary changes what a program receives before those controls appear, which is precisely the behavior older source may have left unstated.

For the first release, Sawyer names strictures and warnings as a minimum intended default. He describes 7.0.0 as effectively 5.32.0 with a small set of changed pragmas and features. The goal is a trivial upgrade between those implementations where possible. This deliberately limits the initial implementation change while establishing a different policy for subsequent major releases.

Signatures illustrate why the distinction between an example and a decision is necessary. Sawyer uses enabling signatures by default as a hypothetical case when discussing upgrade tools. He explicitly marks it as an example. The announcement is insufficient evidence to say that signatures have been selected for the initial default set, or that their experimental status has already changed.

Migration tools must preserve the meaning of old syntax

The same hypothetical identifies a concrete rewriting problem. If signatures become the default, a prototype written in the older subroutine declaration form needs a representation that states its intention unambiguously. Sawyer gives rewriting sub foo ($) as sub foo :prototype($) as the kind of assistance an upgrade utility would provide. The issue is preserving a declaration's interpretation when the surrounding defaults change.

A source transformation can be small in characters while consequential in behavior. Syntax accepted under an older configuration cannot simply be assumed to mean the same thing under a new one. An upgrade utility needs to understand the declaration it changes. Its value comes from preserving that meaning in an explicit form, allowing the application to adopt the new environment without accidentally changing the subroutine's contract.

Sawyer also proposes a compat::perl5 module that restores the pragma and feature defaults of 5.32.0. Its intended purpose is to let a user change the binary before changing the source's assumptions. This is a planned interface. It should not be copied into a current Perl 5 program on the assumption that the announcement itself makes the module available.

Modules introduce a separate complication because an application installs and compiles code that it does not maintain. The proposal includes another module to help toolchain and CPAN infrastructure manage compatibility automatically. That acknowledges that changing the top-level program's settings is insufficient to settle every dependency's interpretation. The specific mechanism remains work to do, rather than a completed guarantee about arbitrary combinations of packages.

My preference is to keep the application author's control visible through that process. Automatically adapting dependencies can reduce manual edits, but it also needs a clear account of which defaults each piece of code receives. The useful criterion is whether a maintainer can explain why an older module retains its meaning after the binary changes.

Support promises and distribution ownership remain separate

The perl5-porters message proposes long-term support for Perl 5 lasting at least five years, while explicitly leaving the exact period undecided. It also says the criteria for maintenance backports need clarification. The intended starting point is the existing maintenance criteria over a longer period. A longer support window and a broader feature-backport policy are different decisions, so one should not be inferred from the other.

Sawyer intends a release within a year and sets an earlier goal of completing it before the end of this year. Both statements are targets. Monthly development releases and yearly minor releases are intended to continue. Those scheduling intentions explain the proposed transition, but they provide no evidence that a final interpreter is already available or that every open design question has a deadline-backed resolution.

The message also states that distributions own /usr/bin/perl. Core developers intend to support vendors in their decisions, rather than dictate what interpreter that pathname selects. This separates upstream language policy from an operating system's deployment policy. An application may depend on a vendor's interpreter selection even when upstream offers a newer binary with an explicit compatibility option.

The announcement leaves substantive decisions open

Sawyer lists choosing defaults, determining support duration, and setting criteria for future major-version changes among the remaining tasks. He also acknowledges that the preceding work was not public and proposes several focused discussion threads. Those statements describe how the plan reached its public announcement without establishing consensus on every detail. A summary of the proposal should preserve that uncertainty without importing arguments or outcomes from later discussion.

The practical significance of Perl 7 today is this proposed separation between implementation continuity and a new default configuration. Existing feature controls demonstrate that some required mechanisms already exist. Compatibility utilities and the exact initial settings still require development. The proposal gives authors of new programs a reason to expect less repeated setup, while leaving maintainers of older code with specific questions about source interpretation, dependency handling, and the duration of the Perl 5 maintenance commitment.