Modern Subroutine Signature Requires Perl Version

InfiniteSilence has asked for the wisdom of the Perl Monks concerning the following question:

I feel like this question has been asked in the past but I could not find it in the search.

So I am running this code snippet from Dave Cross' blog titled, Summarizing a Month of Git Activity with Perl (and a Little Help from AI) and I ran into a new feature of Perl -- subroutines that take named arguments. We had prototypes in the past but people said they were wonky so I avoided them for the most part.

So here I am trying to use this thing and I start getting a weird error:


#!/usr/bin/perl -w
use strict;

# LEARN: weird -- the method has named parameters ... since v5.36

sub commits_for_month ($repo, $since, $until) {
  my $cmd = sprintf(
    q{git -C %s log --since="%s" --until="%s" --pretty=format:"%%s"},
    $repo, $since, $until
  );

  my @commits = `$cmd`;
  chomp @commits;

  return @commits;
}

1;
[download]

I get...,

llegal character in prototype for main::commits_for_month : $repo, $si
+nce, $until at ./gitter.pl line 7.
Global symbol "$repo" requires explicit package name (did you forget t
+o declare "my $repo"?) at ./gitter.pl line 10.
Global symbol "$since" requires explicit package name (did you forget 
+to declare "my $since"?) at ./gitter.pl line 10.
Global symbol "$until" requires explicit package name (did you forget 
+to declare "my $until"?) at ./gitter.pl line 11.
./gitter.pl had compilation errors.
[download]

My Perl version:

This is perl 5, version 40, subversion 1 (v5.40.1) built for x86_64-li
+nux-thread-multi
...
[download]

When I look this up using Google's handy-dandy AI it tells me all about the normal way to get passed-in parameters in a subroutine and then tells me that this new syntax is available in v5.36. So I add,

use v5.36;
[download]

To my code and voila, the code compiles,

 perl -c ./gitter.pl
./gitter.pl syntax OK
[download]

Dave's example didn't specify the version like this in his code. Is there something in my environment I am supposed to set to avoid this from happening?

Celebrate Intellectual Diversity

Comment on Modern Subroutine Signature Requires Perl Version Select or Download Code

Replies are listed 'Best First'.
Re: Modern Subroutine Signature Requires Perl Version by Corion (Patriarch) on Apr 21, 2026 at 14:10 UTC
Subroutine signatures only get enabled if the `signatures` feature, either directly through `use feature 'signatures';` or implicitly through a feature bundle, like `use 5.020;`. This feature is now considered stable, and is enabled automatically by `use v5.36` (or higher). On versions between 5.020 and 5.034, a warning was issued that signatures were experimental. The documentation for feature 'signatures' doesn't mention any further implicit activation, so maybe Dave has something like `use 5.036;` in his environment.	[reply] [d/l] [select]
Re: Modern Subroutine Signature Requires Perl Version by Haarg (Priest) on Apr 21, 2026 at 15:09 UTC
The first code example in the blog post starts with the line `use v5.40;`	[reply] [d/l]
Re: Modern Subroutine Signature Requires Perl Version by haj (Vicar) on Apr 21, 2026 at 15:14 UTC
The very first line of code in Dave's article reads: `use v5.40;` [download] Of course, this line is not repeated for every code snippet.	[reply] [d/l]
Re: Modern Subroutine Signature Requires Perl Version by LanX (Saint) on Apr 21, 2026 at 15:02 UTC
> . Is there something in my environment I am supposed to set to avoid this from happening? No that's not how it's supposed to be. Nonetheless I think it's possible to achieve this and other settings automatically for your installation. The perl.exe will look for a "config" at startup, IIRC. ° * But it'll make exchanging scripts with other environments messy. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery} Updates °) see $Config{sitelib}/sitecustomize.pl *) it's also possible for the shell environment, by aliasing perl to a snippet setting it on startup. Like with `-M` ... I'd personally use another alias tho, like `perlx` IIRC there are also other possible ENV vars available to hack with. For more see `perlrun`	[reply] [d/l] [select]

Updates