Perl 5.33.2 adds a build experiment for default strictures

Changing a language default affects programs that never requested that behavior. Perl 5.33.2 makes strict-by-default behavior available as an interpreter build experiment. Its -Dusedefaultstrict Configure option lets developers examine that change with an actual binary. The option does not establish that every installed Perl now applies strictures automatically, and its documented exceptions make the experiment more specific than that claim would suggest.

The September release notes label the option experimental and intended for development diagnostics. The history file dates the snapshot to September 20. Its other listed changes are bundled module updates. The build option is the substantive new mechanism for examining how existing source behaves when its starting assumptions change.

A build setting changes the initial environment

The Configure source at this tag includes the usedefaultstrict setting and a prompt for strict-by-default behavior. This places the experiment at interpreter construction time. An application's own use strict declaration remains a statement in source. A build setting instead changes what happens before that source has explicitly selected strictures.

That difference determines what the experiment can reveal. A file already enabling strictures is evidence about code written for those checks. A file that omits the declaration can rely on constructs those checks reject. Running the latter under a specially built interpreter tests an implicit assumption that a source-level declaration would otherwise leave untouched. It is a way to find dependence on the starting environment.

The release notes explicitly exempt programs supplied through -e and -E from these strict defaults. Consequently, a successful one-liner does not demonstrate that the same text behaves identically as a file under the experimental binary. The invocation form is part of the test condition. Treating the option as a universal switch would erase a qualification the release documents directly.

I value Perl's suitability for text operations typed once at a shell prompt. Preserving an explicit distinction for command-line code makes this experiment particularly interesting to me. It acknowledges that an interpreter's defaults can affect casual commands differently from maintained source files.

Strictness consists of specific restrictions

The strict pragma documentation bundled with this release defines restrictions for variables, symbolic references, and barewords. Enabling the pragma without a list selects all its restrictions. Their failures occur at different stages, so a broad description such as stronger checking is insufficient to explain what a changed default means.

Variable strictness produces a compile-time error for a variable that is neither explicitly declared nor fully qualified. The documentation names my, our, state, and use vars as declaration mechanisms. It also explains why local alone is insufficient. Localization changes the treatment of a global value without satisfying the requirement to declare or qualify the variable name.

use strict;
use warnings;

my $count = 0;
$count += 1;
print "$count\n";

This program states its own strictness requirements. Its lexical declaration makes the variable's status explicit. The example is ordinary source-level configuration, independent of whether the interpreter was built for the new experiment. That separation makes it possible to describe the behavior without suggesting that users must rebuild Perl to obtain existing strict checks.

Symbolic-reference strictness has a runtime consequence. The pragma documentation contrasts a genuine reference with a string naming a variable. Dereferencing the latter triggers an error under the restriction. A program can therefore compile and still encounter a strictness failure when it executes a particular path. Compilation success alone cannot account for the whole effect of a changed starting configuration.

Bareword strictness rejects identifiers in contexts where the interpreter might otherwise accept them as unquoted strings. Its documented exceptions include simple hash keys and identifiers to the left of the fat comma. Those exceptions are relevant to compatibility because enabling strictures does not require every bare-looking key in an existing program to acquire quotes. The restriction follows syntax-specific rules.

Development diagnostics require an identified binary

The option's purpose is to expose assumptions in source, but a result depends on the build used to run it. A report needs to distinguish an explicit pragma, the experimental build configuration, and the command-line exception. Otherwise two maintainers can execute similar-looking programs and observe different results without disagreeing about the source itself. The pragma also permits restrictions to be disabled locally, so the enclosing source scope remains relevant to interpreting a result.

My preference is to record these conditions directly when discussing interpreter compatibility. The September snapshot supplies a mechanism for investigating a possible default, while the existing pragma explains the checks that default would select. Its scope is useful precisely because it is identifiable. A developer can examine undeclared variables and symbolic-reference behavior under the experiment without claiming that Perl has already changed the language environment of every ordinary installation.