Name

If present, it specifies the name of the function being defined. As with sub, if a name is present, by default the whole declaration is syntactically a statement and its effects are performed at compile time (i.e. at runtime you can call functions whose definitions only occur later in the file - but see the runtime flag below). If no name is present, the declaration is an expression that evaluates to a reference to the function in question.

Attributes

Attributes are relatively unusual in Perl code, but if you want them, they work exactly the same as with sub.

Prototype

As with sub, a prototype, if present, contains hints as to how the compiler should parse calls to this function. This means prototypes have no effect if the function call is compiled before the function declaration has been seen by the compiler or if the function to call is only determined at runtime (e.g. because it's called as a method or through a reference).

With sub, a prototype comes directly after the function name (if any). Function::Parameters reserves this spot for the parameter list. To specify a prototype, put it as the first attribute (e.g. fun foo :(&$$)). This is syntactically unambiguous because normal attributes need a name after the colon.

You can also use an attribute named prototype (e.g. fun foo :prototype(&$$)). In that case it does not have to be the first attribute. This syntax is also compatible with sub in perl 5.20 and newer.

Parameter list

The parameter list is a list of variables enclosed in parentheses, except it's actually a bit more complicated than that.

Instead of a full variable name (such as $foo or @bar) you can write just the sigil ($, @, or %). This has the effect of creating an unnamed parameter, which is useful in functions that are called with a certain number of arguments but want to ignore one or more of them. This trick works for invocants, slurpies, and positional parameters (see below). You can't have unnamed named parameters for what I hope are obvious reasons.

A parameter list can include the following 6 parts, all of which are optional:

1. Invocant

This is a scalar variable followed by a colon (:) and no comma. If an invocant is present in the parameter list, the first element of @_ is automatically shifted off and placed in this variable. This is intended for methods:

The most common kind of parameter. This is simply a comma-separated list of scalars, which are filled from left to right with the arguments that the caller passed in:

fun add($x, $y) {
return $x + $y;
}
say add(2, 3); # "5"

3. Optional positional parameters

Parameters can be marked as optional by putting an equals sign (=) and an (optional) expression (the "default argument") after them. If no corresponding argument is passed in by the caller, the default argument will be used to initialize the parameter:

Using just a = with no expression after is equivalent to specifying = undef, i.e. the corresponding parameter is optional and has a default value of undef.

The default argument is not cached. Every time a function is called with some optional arguments missing, the corresponding default arguments are evaluated from left to right. This makes no difference for a value like 2 but it is important for expressions with side effects, such as reference constructors ([], {}) or function calls.

Default arguments see not only the surrounding lexical scope of their function but also any preceding parameters. This allows the creation of dynamic defaults based on previous arguments:

That is, the caller must specify a key name in addition to the value, but in exchange the order of the arguments doesn't matter anymore. As with hash initialization, you can specify the same key multiple times and the last occurrence wins:

Provides completely custom keywords as described by their types. A "type" is either a string (one of the predefined types function, method, classmethod, function_strict, method_strict, classmethod_strict) or a reference to a hash with the following keys:

defaults

Valid values: One of the predefined types function, method, classmethod, function_strict, method_strict, classmethod_strict. This will set the defaults for all other keys from the specified type, which is useful if you only want to override some properties:

CAVEAT: A future version of this module may enable runtime => 1 by default for methods.

shift

Valid values: strings that look like scalar variables. This lets you specify a default invocant, i.e. a function defined with this keyword that doesn't have an explicit invocant in its parameter list will automatically shift its first argument into the variable specified here.

invocant

Valid values: booleans. If you set this to a true value, the keyword will accept invocants in parameter lists; otherwise specifying an invocant in a function defined with this keyword is a syntax error.

attributes

Valid values: strings containing (source code for) attributes. This causes any function defined with this keyword to have the specified attributes (in addition to any attributes specified in the function definition itself).

default_arguments

Valid values: booleans. This property is on by default; use default_arguments => 0 to turn it off. This controls whether optional parameters are allowed. If it is turned off, using = in parameter lists is a syntax error.

check_argument_count

Valid values: booleans. If turned on, functions defined with this keyword will automatically check that they have been passed all required arguments and no excess arguments. If this check fails, an exception will by thrown via Carp::croak.

check_argument_types

Valid values: booleans. This property is on by default; use check_argument_types => 0 to turn it off. This controls whether functions defined with this keyword automatically check that the arguments they are passed pass the declared type constraints (if any). See "Experimental feature: Types" below.

strict

Valid values: booleans. This turns on both check_argument_count and check_argument_types.

reify_type

Valid values: code references. The function specified here will be called to turn type annotations into constraint objects (see "Experimental feature: Types" below). It will receive two arguments: a string containing the type description, and the name of the current package.

Introspection

You can ask a function at runtime what parameters it has. This functionality is available through the function Function::Parameters::info (which is not exported, so you have to call it by its full name). It takes a reference to a function, and returns either undef (if it knows nothing about the function) or a Function::Parameters::Info object describing the parameter list.

Note: This feature is implemented using Moo, so you'll need to have Moo installed if you want to call Function::Parameters::info (alternatively, if Moose is already loaded by the time Function::Parameters::info is first called, it will use that instead).

Experimental feature: Types

An experimental feature is now available: You can annotate parameters with types. That is, before each parameter you can put a type specification consisting of identifiers (Foo), unions (... | ...), and parametric types (...[...]). Example:

If you are in "lax" mode, nothing further happens and the types are ignored. If you are in "strict" mode, Function::Parameters generates code to make sure any values passed in conform to the type (via $constraint->check($value)).

Experimental experimental feature: Type expressions

An even more experimental feature is the ability to specify arbitrary expressions as types. The syntax for this is like the literal types described above, but with an expression wrapped in parentheses (( EXPR )). Example:

fun foo(('Int') $n, ($othertype) $x) { ... }

Every type expression must return either a string (which is resolved as for literal types), or a type constraint object (providing check and get_message methods).

Note that these expressions are evaluated (once) at parse time (similar to BEGIN blocks), so make sure that any variables you use are set and any functions you call are defined at parse time.

How it works

The module is actually written in C and uses PL_keyword_plugin to generate opcodes directly. However, you can run perl -MO=Deparse ... on your code to see what happens under the hood. In the simplest case (no argument checks, possibly an invocant, required positional/slurpy parameters only), the generated code corresponds to: