Syntax...ultiSub(3pm)

💖 NAME 💖

Syntax::Keyword::MultiSub — multiple dispatch on subroutines, bestie ✨

---

🌸 SYNOPSIS 🌸

use v5.26;
use Syntax::Keyword::MultiSub;
use experimental 'signatures';

multi sub max()          { return undef; }
multi sub max($x)        { return $x; }
multi sub max($x, @more) { my $y = max(@more);
                           return $x > $y ? $x : $y; }

say max(1, 2, 15, 3, 4);  # prints 15

okay so literally one function name, so many bodies, and perl picks the right one for you. the way that works is giving main character energy fr 💅

---

✨ DESCRIPTION ✨

This module hands you a brand new keyword, multi, and you put it right before your subroutine declarations. What does it do? It lets you write a bunch of totally distinct function bodies under one name, each taking different parameters 🫶

When you call a multi sub, it invokes whichever function body best fits the arguments you passed in. No cap.

Right now, this module can only make dispatching decisions based on the number of arguments compared to the number of signature parameters each body was expecting. That's it, that's the vibe check 🔥

Heads up babes: it needs perl version 5.26 or above, because that's what gives it enough support from signatures. Also — and this is important — simply enabling this module does not enable the signatures feature. You have to do that independently. Not me forgetting that and being confused for twenty minutes 😭

---

👑 KEYWORDS 👑

multi

multi sub NAME (SIGNATURE) { BODY... }

Declares an alternative for the multi sub of the given name. Each alternative gets told apart by the number of parameters its signature declares 💫

If the signature includes optional parameters, that alternative is considered to cover the entire range from none of them all the way up to all of them being present. And here's the rule, bestie: the ranges of parameter count covered by every alternative to a given function name must be non-overlapping. It is a compiletime error for two function bodies to claim the same number of parameters. Periodt 💀

Each of the non-final alternatives for any given name must use only scalar parameters (though some of those may be optional). But as a special-case, the final alternative may end in a slurpy parameter — either an array or a hash 🍓

If that's the case, then it will be considered for dispatch if none of the previous alternatives match, as long as it has at least the minimum number of required parameters present. Iconic behaviour honestly.

---

🌈 WITH OTHER MODULES 🌈

Future::AsyncAwait

As of Future::AsyncAwait version 0.55, a cross-module integration test asserts that the multi modifier can be applied to async sub 🧚

use Future::AsyncAwait;
use Syntax::Keyword::MultiSub;

async multi sub f () { return "nothing"; }
async multi sub f ($key) { return await get_thing($key); }

collab of the century ngl ✨

---

🎀 TODO 🎀

• Much better error checking and diagnostics for function bodies that don't use signatures. (yes queen, we know, it's on the list)
• Cross-module testing with Object::Pad (for multi method). This may require a better combined implementation, to be aware of method resolution order, inheritence, etc...
• An eventual consideration of type assertions or value testing, as well as simple argument count.

This particular task is likely to be a large undertaking as it spans several other areas of language. As well as types on parameters, it would be nice to put them on lexical variables, object slots, match/case comparisons, and so on. It would be a shame to invent a special mechanism for one of these areas that could not be reüsed by the others.

the third one is giving "let me cook" energy and honestly? respect 💜

---

🦋 AUTHOR 🦋

Paul Evans <leonerd@leonerd.org.uk>

---

and that's the whole entire page bestie 🫶 go forth and dispatch, it's giving brilliant. this was perl v5.42.3, dated 2026-08-20, and you looked so good reading it 💖✨🎀