Perl 5.32's first candidate makes compatibility changes concrete

The string "0" looks harmless at the start of a range, but Perl has treated it differently from the number 0. In the first Perl 5.32 release candidate, that special case changes. A range that previously generated numeric strings can now be empty. This is the sort of compatibility detail that makes a release candidate useful to maintainers of existing code, even when none of the new language facilities is relevant to their application.

The history file at the RC0 tag records May 30 as the candidate's date. Its bundled release notes collect changes against 5.30.0. They describe the intended 5.32 interpreter, but this artifact remains a candidate. Its existence provides an implementation to exercise before treating those changes as a routine stable upgrade.

A single zero stops selecting string increment behavior

The notes document the old result of "0" .. "-1" as strings beginning with "0" and continuing through "99". The new result is an empty list, matching 0 .. -1. They also say "0" .. "9" now produces integers where it previously produced strings. Both changes follow from treating the plain zero string as a number for the range operator.

The motivating distinction is between a plain zero and strings whose leading zeros are meaningful to string increment. The notes give "00" .. "03" as the reason the interpreter had special treatment for strings starting with zero. Such a range produces padded strings. Extending that treatment to the single-character string "0" produced the surprising boundary case. The candidate separates the two cases instead of discarding padded string ranges.

my @empty = "0" .. "-1";
my @padded = "00" .. "03";

The first array is empty under the candidate's documented behavior. The second expresses the padded sequence that motivated the older special handling. An application can care about this even if it later stringifies every element. Changing how many elements exist is independent of their final formatting.

I favor Perl for small text transformations because it can express operations such as these directly. That convenience makes the distinction between numeric and string behavior consequential. A compact expression still needs a defined interpretation at its boundaries, particularly when values originate as strings.

Constants cannot retain a modifiable variable this way

Another compatibility change affects anonymous constant subroutines that refer to a variable modified elsewhere. The notes show an empty-prototype subroutine returning a lexical variable and say that this construction now raises an exception when the subroutine is defined. The form has been deprecated since 5.22. This candidate turns the previous warning period into an enforced restriction.

The documented adjustment is to make the return explicit:

my $var;
my $sub = sub () { return $var };

The added return is significant because it avoids the restricted constant form. It does not make the referenced variable immutable. A maintainer needs to decide whether the code intends a constant or a subroutine that retrieves a variable's current value. Those intentions should not be conflated merely because the earlier interpreter accepted the same short body for both.

Bit operations require the right kind of string

The candidate also forbids vec on strings containing code points above 0xFF. The release notes explain why this boundary matters. Such strings use an internal UTF-8 representation, while vec performs bit-oriented work. Applying a bit operation to that representation can give results that do not correspond to the character-level intention of the program. The restriction follows a deprecation introduced in 5.28.0.

Remaining uses of code points above 0xFF in string bitwise operators are prohibited too. These changes have a narrower meaning than a general rejection of Unicode strings. They concern operations that interpret a string as bits. Programs doing character processing and programs manipulating packed binary data need different assumptions about the value presented to the operator.

The notes also remove purported support for POSIX::mbstowcs and POSIX::wcstombs, explaining that a defective interface specification prevented those functions from working. That is different from removing a functioning facility after a normal migration period. The release documentation identifies the distinction, which prevents a compatibility review from inventing a supported historical contract where none existed.

Unicode property lookup has a compatibility change of its own. User-defined properties now consistently override official properties with the same name. Previously the result depended on whether the user definition preceded pattern compilation. The notes explain that consistent overriding protects an established custom property against a future Unicode property acquiring the same name. Here a behavioral change removes dependence on declaration timing.

My preference is for these boundaries to be explicit even when enforcement exposes old assumptions. The candidate also adds Unicode 13 support and an experimental isa operator, but existing applications can encounter changes without adopting either. May's artifact gives maintainers the complete candidate interpreter, including restrictions that earlier deprecations anticipated and the corrected range behavior. A useful compatibility result therefore includes the output and failure behavior of existing expressions, alongside whether the application still parses.