Perl Subroutine Signatures: Cleaner Parameters Starting in 5.36

The boilerplate problem

If you have written Perl utilities for any length of time, you have probably started subroutines with this line:

my ($name, $count, $options) = @_;

It works, but it is easy to mistype a variable name, forget to shift the invocant in an object method, or accidentally ignore extra arguments. Perl 5.36 made subroutine signatures a stable language feature, so you can declare parameters directly in the sub line instead. If your deployment targets run Perl 5.36 or newer, you can remove that boilerplate today. If they run older Perl, signatures still require use feature 'signatures' and may emit experimental warnings, so check the interpreter before committing signature-based code.

What signatures look like

A subroutine signature is the parenthesized parameter list that appears immediately after the subroutine name. It replaces the manual unpacking of @_.

use v5.36;
use warnings;

sub format_label ($label, $prefix = 'info') {
    return "$prefix: $label";
}

sub build_user ($name, $role = 'reader', @groups) {
    return { name => $name, role => $role, groups => \@groups };
}

The first example gives $prefix a default value, so callers can omit it. The second slurps remaining arguments into @groups, which is useful for variadic utilities. Inside the body, the variables are already lexical and scoped to the subroutine, so there is no @_ indexing to mistype.

Check your Perl version first

Before using signatures in production, confirm the interpreter on each target host.

perl -V

Run this in a terminal. No special permissions are required. In the summary output, confirm that revision is 5 and version is 36 or greater. If the number is lower, signatures are not stable on that installation.

You can also probe the feature directly:

perl -e 'use v5.36; sub ping ($text) { print "$text\n" } ping("signature check");'

Run this in a terminal. No special permissions are required. Expect it to exit without an experimental::signatures warning. If you see that warning, the Perl is older than 5.36 or signatures are not enabled in that build.

Trade-offs and limitations

• Signatures are positional only. Perl does not provide native named arguments through this feature, so callers must pass arguments in the declared order.
• Mixing signatures with subroutine prototypes or manual @_ manipulation can cause parsing conflicts or unexpected behavior. Pick one style per subroutine.
• Older Perl releases require use feature 'signatures' and treat the feature as experimental, which can produce warnings under use warnings.

Practical adoption path

1. Run perl -V on every deployment target and confirm version 5.36 or later.
2. Add use v5.36; and use warnings; to new utility modules.
3. Convert one internal, well-tested subroutine at a time rather than rewriting an entire codebase.
4. Run the module's test suite with warnings enabled and check that no experimental::signatures messages appear.

If a target host cannot upgrade yet, keep the my ($x, $y) = @_; idiom there and reserve signatures for modules that run only on 5.36 or newer.