Perl 5.40 RC1 tests the compatibility work behind the new syntax
The first 5.40 release candidate includes stricter import diagnostics and large-string fixes, alongside a deliberate retreat on experimental delimiters.
A misspelt module name can load a file successfully and still fail to enable the behaviour the programmer requested. The 5.40 release candidate documents a case involving use STRICT 'refs' on a case-insensitive filesystem. The file can resolve to strict.pm, but the differently cased package name means the intended import never happens. Earlier Perl could let that mistake pass silently.
This is one of the compatibility changes worth examining in Perl 5.40.0-RC1, released by Graham Knop on 24 May according to the release history. The candidate's release notes compare the planned release with 5.38.0. They expose changes to established behaviour as well as the more visible language additions.
I tend to value Perl most when the program stays small enough to inspect directly. Silent failure in a declaration is particularly unwelcome there. A statement near the top of a script should establish the behaviour it appears to request, and a useful diagnostic can make that assumption checkable.
An unknown import stops looking successful
The candidate warns when import or unimport receives arguments for an unknown package. Earlier interpreters, according to the notes, treated those method names specially when no method existed. The new arrangement gives UNIVERSAL an import method, making the behaviour explicit through inheritance.
There is a compatibility boundary within that change. Calling an unknown package's import method without arguments continues to succeed silently. With arguments, Perl can warn that the requested import has no implementation. That also affects packages that intentionally define classes without an import method when callers pass them arguments.
The case-insensitive filesystem example explains the motivation. Successful file lookup does not establish that the package named by the caller implemented the requested action. The release candidate creates an opportunity for module maintainers to observe those warnings in their actual load paths, including paths that ordinary syntax checks may not make obvious.
This is not an instruction to add a meaningless import method everywhere. The diagnostic points to a mismatch between a caller's request and a package's behaviour. The appropriate resolution depends on whether the arguments were intentional or whether the caller has the wrong package name.
Large strings need large offsets throughout
The notes also collect fixes where internal code used I32 for a string offset or size that required SSize_t, STRLEN or size_t. That is a recurring compatibility problem in an implementation that can represent data larger than the assumptions of one internal operation.
The candidate documents several consequences. Negating a string larger than 2 GB could do nothing or return an incomplete result. Repeating such a string could throw an error. Complex substitutions after the 2 GB position could use incorrect or invalid offsets. These are different user-visible operations affected by the size representations underneath them.
Hash keys illustrate a different response to a limit. The notes say keys larger than 2 GB remain unsupported. When constant folding produces such a key, the compiler now reports an error instead of truncating its length while constructing the shared scalar. Supporting a large string in one operation does not imply support for every structure that might contain it.
The useful distinction is between correcting an operation to handle its supported size and rejecting input outside another operation's supported size. Both are improvements over silently using a truncated internal length. The release candidate gives maintainers specific behaviour to compare when their programs manipulate large buffers.
Experimental status changed before the candidate
The candidate also records a reversal concerning extra_paired_delimiters. Developers removed the Syriac colon delimiter pair because its right-to-left writing direction could cause visual confusion. The policy change forbids right-to-left delimiters, with that pair being the current example affected.
According to the notes, this change means the feature has not been stable long enough to remove its experimental status. That is relevant after the April development snapshot described the feature as stabilised. A release candidate needs to be read on its own terms. A statement about an earlier snapshot's feature status is not a guarantee about the candidate.
The release notes link the discussion about the delimiter pair. The concrete concern is how source text is read, not whether the parser can accept another pair of Unicode characters. A visually confusing delimiter can make the program harder to interpret even when the syntax has an unambiguous implementation.
Internal experiments remain distinct from defaults
The candidate introduces the PERL_RC_STACK build option as highly experimental and disabled by default. Under it, pushing scalars onto the argument stack increases their reference counts. The notes describe the implementation as incomplete and slow, with XS calls going through a compatibility wrapper.
That work should not be confused with a default change in the candidate. Its presence documents a development direction and supplies an implementation for investigation. The ordinary build retains its existing choice. Module maintainers need to identify which interpreter configuration a result describes before attributing its behaviour to the whole release.
I appreciate a candidate whose notes distinguish those cases. The useful compatibility review concerns actual changes in declarations, string operations and feature status. The candidate also adds facilities such as generated class-field readers, but its readiness depends on existing modules retaining correct behaviour under the less visible changes in the interpreter and its bundled libraries.