Perl 5.42's first release candidate makes compatibility choices concrete

Perl's next release has to decide which old syntax remains available and which new declarations impose stricter rules. The first release candidate makes those decisions inspectable in a specific interpreter. The history records date Perl 5.42.0-RC1 to June 24, and the candidate's release notes describe the accumulated differences from 5.40.0.

A release candidate is a useful point for module compatibility work because its proposed behavior can be examined as a whole. Testing an isolated development change answers whether that change works. Testing this candidate asks whether the resulting collection of language rules and implementation changes works for an existing distribution.

I value Perl for concise text processing, while wanting old programs to remain understandable. This candidate interests me because its compatibility decisions often involve explicit lexical declarations. The code can say which rules it wants without requiring every source file running under the interpreter to adopt the same policy.

Source encoding becomes a declared constraint

The candidate includes the new source::encoding pragma. It accepts ASCII or UTF-8 as the source policy for the remainder of its lexical scope. Its UTF-8 form is equivalent to use utf8. The stated purpose is to catch cases where a program contains source characters that needed an explicit UTF-8 declaration.

The stricter ASCII policy is enabled within the lexical scope of a version declaration for 5.41.0 or higher. That makes adoption of the newer language bundle relevant to parsing source. Running a file under a newer executable and writing a newer version declaration in that file are distinct changes.

A module maintainer encountering a source-encoding error therefore has a more precise question than whether the new interpreter understands Unicode. The question is what the source declares and which characters its declaration permits. Text read from a file at runtime is a separate concern from the bytes used to spell the program itself.

The candidate also permits turning off the checks with no source::encoding. Its notes say that non-ASCII characters then have undefined meaning. That is a description of the unchecked policy, not a substitute for declaring UTF-8 source when that is what the file contains. A useful compatibility report identifies the declaration and source bytes involved.

Planned removals have become feature boundaries

The candidate notes explicitly retain switch and smartmatch. They recount the earlier deprecation and scheduled removal, then explain that removal has been postponed indefinitely after discussion. This is a significant difference between testing a candidate and treating an old deprecation schedule as a description of the final implementation.

Switch still requires its feature flag. Smartmatch now requires a feature flag too, with older bundles enabling it and the newer bundle disabling it. A program can separately request the feature. The candidate therefore preserves availability while changing what a newer language declaration enables by default.

This arrangement has two compatibility dimensions. An interpreter may still implement an operation that a particular lexical scope has not enabled. A failure to compile in that scope is different from removal of the implementation. Reports that include the version declaration and feature requests can distinguish those cases.

The apostrophe package separator has a similar history in the notes. It was deprecated, removed during development, and reinstated by default after discussion. A feature controls its use in source, while symbolic references retain their internal conversion behavior. Candidate testing can expose code that depends on either path without assuming both paths have identical rules.

Core testing and module testing answer different questions

The candidate's installation instructions provide the source build sequence, including configuration, compilation, and make test. They also document a configurable installation prefix. That supports keeping a candidate installation distinct when examining its behavior, rather than treating installation over an existing interpreter as necessary for investigation.

The core suite checks the interpreter against the tests distributed with it. A module's suite adds assumptions from another codebase. Those assumptions may concern documented syntax, a parser behavior the module never stated, or an implementation detail that its tests happen to exercise. A candidate result becomes useful when the failing assumption can be reduced to an example.

The release notes ask for a small but sufficient test case when reporting a bug. For a source-policy failure, that can mean preserving the exact declaration and offending character. For a changed feature default, it means retaining the bundle selection. Removing those details while reducing the test can remove the condition that explains the result.

My interest in a candidate is strongest where a compatibility question has a specific answer. The current notes establish that smartmatch remains implemented and that source encoding can become explicitly checked. A report should establish which of those published rules it is testing before interpreting every new diagnostic as a runtime regression.

RC1 is available now as the first candidate for this release. Its source and versioned documentation provide a common reference for reproductions. Module compatibility work can proceed against that exact candidate, including the lexical policy choices that determine which syntax a source file is allowed to use.