Perl 5.35.3 makes a version declaration enable warnings

A version declaration can now establish that a Perl program wants warnings. The 5.35.3 release notes say that use v5.35 or a higher version enables all warnings within its scope. This changes what the declaration communicates to the interpreter. A program selecting that version receives diagnostic checks without needing a separate use warnings for the same scope.

The scope qualification is important. This is not a command-line setting that indiscriminately changes every file loaded by a process. The warnings documentation shipped in this release explains lexical control and explicitly notes that settings do not leak into files loaded through use, require, or do. A module can continue to establish its own warning policy.

I like a short Perl program to state its assumptions near the beginning. A version declaration is already a natural place for the reader to look for language requirements. Enabling diagnostics there reduces the declarations needed for code that deliberately selects modern behaviour, while preserving a place for narrower exceptions.

A version line now includes diagnostic policy

This example uses the new declaration and then demonstrates a local exception. The same undefined value is used in two concatenations, with the uninitialized category disabled only around the second operation.

use v5.35;

my $missing;
my $first = "value=" . $missing;

{
    no warnings 'uninitialized';
    my $second = "value=" . $missing;
}

The outer scope receives all warnings through the version declaration. The inner block states a more limited policy for one category. That local declaration does not erase the enclosing policy for later statements outside the block. The mechanism remains the lexical warning system documented by the pragma, with a new way to enable it.

There is a useful distinction between choosing an interpreter requirement and merely running an older script on a newer binary. The release describes a source declaration as the trigger. It does not say that every script executed by 5.35.3 has all optional warnings enabled. This avoids treating the development release as a global rewrite of the diagnostic behaviour of legacy source.

Similarly, all warnings does not mean all warnings become fatal. The announcement describes enabling diagnostics, not changing each diagnostic into an exception. A program that has its own policy for fatal warnings needs to treat that as a separate decision. Conflating the two can turn an explanation of additional visibility into an unsupported claim about failed execution.

Lexical warnings preserve module independence

The pragma documentation contrasts lexical warning control with the -w flag and $^W. Lexical declarations let authors choose checks for their own code. The unit of control is the enclosing block, and file boundaries prevent an importing module from silently imposing its settings on a dependency. The new version-based default works within that established model.

That design has a practical maintenance benefit. Source can adopt a newer version and review its own diagnostics without first deciding how every library should be checked. A warning in the calling module and a warning in a dependency belong to different declarations. The choice is readable in source instead of depending only on how a launcher happened to invoke Perl.

This release's documentation also describes negative warning categories, available since 5.34. A category prefixed with - can be disabled in a use warnings argument list, whose items are processed in order. The existing separate no warnings form remains useful when the intent is to explain one narrow exception near the code that needs it.

The difference is one of presentation and scope, not a reason to suppress broad groups without examining them. A declaration such as no warnings 'uninitialized' identifies which diagnostic the author expects. A blanket suppression communicates much less about the operation. For compact text-processing code, that additional specificity is often worth the line it occupies.

Feature bundles can change without removing syntax

The release notice also removes the experimental switch feature from the bundle named for v5.36. This is a change made in the current development release's bundle definitions, not a claim about a later release having shipped. Programs that want that experiment must enable it explicitly under the revised bundle. The feature's existence and its inclusion in a default bundle are separate questions.

That distinction complements the warnings change. A version bundle can specify which language facilities a program receives implicitly, while explicit feature declarations can select additional syntax. The release also adds a simple API for inspecting enabled features and bundles. Tools need access to those settings because a version line is becoming a more substantial description of the compilation environment.

I prefer this direction when it makes a program's selected behaviour easier to explain. Diagnostics help expose mistakes, and explicit experimental declarations help identify intentional departures from a bundle. Neither eliminates the need to understand the code, but both provide information before a reader has to infer policy from individual expressions.

The immediate change in August is precise. Code declaring v5.35 or higher enables all warnings in that lexical scope. Existing warning declarations still control categories and blocks, and separately loaded files retain their own settings. That gives a modern source declaration a documented diagnostic meaning without claiming that every Perl program now shares one warning policy.