Perl 5.41.2 makes source encoding an explicit restriction

A source file can contain an unintended non-ASCII character without its author intending to write a Unicode program. Perl 5.41.2 introduces source::encoding to make that situation diagnosable. A scope can declare that its source is ASCII, and the interpreter then rejects a character outside that set. A separate declaration explicitly allows UTF-8 source.

The Perl release history dates 5.41.2 to 20 July. Its release notes identify the new pragma as a way to catch a forgotten use utf8 early. That purpose is more specific than adding support for another encoding. The pragma accepts only ASCII and UTF-8, and the UTF-8 form is equivalent to the existing declaration.

I value explicit source assumptions in short Perl programs. Dense text-processing code is already sensitive to punctuation and quoting. A compiler error for an unexpected source character is more useful than asking a later reader to infer whether the character was intentional.

An ASCII declaration can reject a mistake

The pragma's implementation and documentation describe two ordinary choices. A file can use only ASCII source and express other characters through escapes. Alternatively, it can declare that the source bytes contain UTF-8 characters. A character that fits neither choice is often a typographical error.

The ASCII mode provides a restriction the program can ask the compiler to enforce. It also turns off any UTF-8 expectations in that scope. The documentation notes the corresponding ASCII-equivalent behaviour for EBCDIC systems, so its stated restriction follows the platform's representation rather than assuming that every supported machine has the same byte encoding.

An ASCII-only example can still describe a non-ASCII character through an escape. The declaration concerns how the source text itself is written, which is separate from the characters a string value can represent.

use strict;
use warnings;
use source::encoding 'ascii';

my $e_acute = "\x{e9}";

All characters physically written in that example are ASCII. The escaped value does not contradict the source declaration. This makes the mode useful for a project that intentionally keeps its source text within that character set while handling broader text values.

UTF-8 source keeps the existing meaning

The new UTF-8 form is a synonym for use utf8. It does not define a second interpretation of UTF-8 source. The pragma implementation delegates that branch to the existing utf8 import, which makes the equivalence visible in code as well as documentation.

use strict;
use warnings;
use source::encoding 'utf8';

my $label = "café";

Here the literal contains a non-ASCII character and the declaration states how the source encodes it. The spelling groups both supported source policies under one pragma. Existing code can continue to use use utf8, because the release notes explicitly permit the two forms interchangeably.

Neither form claims to select an encoding for a file that a program later reads. The documentation names source code and lexical scope as its subject. Conflating that with input data would assign the pragma a responsibility it does not describe. A source declaration tells the interpreter how to accept the program text, while the program's data still has its own interpretation.

The development version selects ASCII checking

The release automatically enables ASCII mode within the scope of use v5.41.0 or higher. That is a deliberate default for source choosing the new development-version behaviour. It does not mean that every existing program run by the snapshot automatically acquires the restriction.

The declaration is lexical. Its effect applies to the remainder of the pragma's scope, and no source::encoding disables the checks for its own remaining scope. The documentation says that the meaning of non-ASCII characters is then undefined. Disabling the restriction therefore does not request a third supported encoding.

That distinction makes an explicit UTF-8 declaration the meaningful choice for source that intentionally contains those characters. Turning checking off can remove a diagnostic, but it does not state the interpretation the author intended. The restricted pair of accepted arguments keeps that difference visible.

I prefer this to inferring intent from the source character that happened to appear. There are legitimate reasons to choose either policy. Requiring a declaration when the program leaves an ASCII-only default gives a maintainer a concrete statement to read.

Other changes align representations with their contracts

The snapshot also corrects chdir to return real booleans, as its documentation specifies. The release notes identify an observable difference for failure. Its result now stringifies to an empty string instead of the character 0. Both are false values, so code that only branches on truth can behave the same while code that records the returned representation observes a change.

Another update makes B::Deparse understand ^^, the symbolic logical exclusive-or operator. Supporting syntax in the interpreter and reproducing it through deparsing are separate pieces of tooling work. Their presence in different releases explains why module authors need the actual snapshot's notes when assessing compatibility.

For July, the new source restriction is the clearest user-facing addition. It turns an implicit assumption about program text into a lexical declaration with a compilation error when the assumption fails. Its UTF-8 option preserves an established meaning, while its ASCII option gives programs a way to reject characters they never meant to contain.