+to cheat if you know what you're doing. See L</Prototypes> below.
+X<&>
+
+Since Perl 5.16.0, the C<__SUB__> token is available under C<use feature
+'current_sub'> and C<use 5.16.0>. It will evaluate to a reference to the
+currently-running sub, which allows for recursive calls without knowing
+your subroutine's name.
+
+ use 5.16.0;
+ my $factorial = sub {
+ my ($x) = @_;
+ return 1 if $x == 1;
+ return($x * __SUB__->( $x - 1 ) );
+ };
+
+The behavior of C<__SUB__> within a regex code block (such as C</(?{...})/>)
+is subject to change.
+
+Subroutines whose names are in all upper case are reserved to the Perl
+core, as are modules whose names are in all lower case. A subroutine in
+all capitals is a loosely-held convention meaning it will be called
+indirectly by the run-time system itself, usually due to a triggered event.
+Subroutines whose name start with a left parenthesis are also reserved the
+same way. The following is a list of some subroutines that currently do
+special, pre-defined things.
+
+=over
+
+=item documented later in this document
+
+C<AUTOLOAD>
+
+=item documented in L<perlmod>
+
+C<CLONE>, C<CLONE_SKIP>
+
+=item documented in L<perlobj>
+
+C<DESTROY>, C<DOES>
+
+=item documented in L<perltie>
+
+C<BINMODE>, C<CLEAR>, C<CLOSE>, C<DELETE>, C<DESTROY>, C<EOF>, C<EXISTS>,
+C<EXTEND>, C<FETCH>, C<FETCHSIZE>, C<FILENO>, C<FIRSTKEY>, C<GETC>,
+C<NEXTKEY>, C<OPEN>, C<POP>, C<PRINT>, C<PRINTF>, C<PUSH>, C<READ>,
+C<READLINE>, C<SCALAR>, C<SEEK>, C<SHIFT>, C<SPLICE>, C<STORE>,
+C<STORESIZE>, C<TELL>, C<TIEARRAY>, C<TIEHANDLE>, C<TIEHASH>,
+C<TIESCALAR>, C<UNSHIFT>, C<UNTIE>, C<WRITE>
+
+=item documented in L<PerlIO::via>
+
+C<BINMODE>, C<CLEARERR>, C<CLOSE>, C<EOF>, C<ERROR>, C<FDOPEN>, C<FILENO>,
+C<FILL>, C<FLUSH>, C<OPEN>, C<POPPED>, C<PUSHED>, C<READ>, C<SEEK>,
+C<SETLINEBUF>, C<SYSOPEN>, C<TELL>, C<UNREAD>, C<UTF8>, C<WRITE>
+
+=item documented in L<perlfunc>
+
+L<< C<import> | perlfunc/use >>, L<< C<unimport> | perlfunc/use >>,
+L<< C<INC> | perlfunc/require >>
+
+=item documented in L<UNIVERSAL>
+
+C<VERSION>
+
+=item documented in L<perldebguts>
+
+C<DB::DB>, C<DB::sub>, C<DB::lsub>, C<DB::goto>, C<DB::postponed>
+
+=item undocumented, used internally by the L<overload> feature
+
+any starting with C<(>
+
+=back
+
+The C<BEGIN>, C<UNITCHECK>, C<CHECK>, C<INIT> and C<END> subroutines
+are not so much subroutines as named special code blocks, of which you
+can have more than one in a package, and which you can B<not> call
+explicitly. See L<perlmod/"BEGIN, UNITCHECK, CHECK, INIT and END">
+
+=head2 Signatures
+
+B<WARNING>: Subroutine signatures are experimental. The feature may be
+modified or removed in future versions of Perl.
+
+Perl has an experimental facility to allow a subroutine's formal
+parameters to be introduced by special syntax, separate from the
+procedural code of the subroutine body. The formal parameter list
+is known as a I<signature>. The facility must be enabled first by a
+pragmatic declaration, C<use feature 'signatures'>, and it will produce
+a warning unless the "experimental::signatures" warnings category is
+disabled.
+
+The signature is part of a subroutine's body. Normally the body of a
+subroutine is simply a braced block of code. When using a signature,
+the signature is a parenthesised list that goes immediately after
+the subroutine name (or, for anonymous subroutines, immediately after
+the C<sub> keyword). The signature declares lexical variables that are
+in scope for the block. When the subroutine is called, the signature
+takes control first. It populates the signature variables from the
+list of arguments that were passed. If the argument list doesn't meet
+the requirements of the signature, then it will throw an exception.
+When the signature processing is complete, control passes to the block.
+
+Positional parameters are handled by simply naming scalar variables in
+the signature. For example,
+
+ sub foo ($left, $right) {
+ return $left + $right;
+ }
+
+takes two positional parameters, which must be filled at runtime by
+two arguments. By default the parameters are mandatory, and it is
+not permitted to pass more arguments than expected. So the above is
+equivalent to
+
+ sub foo {
+ die "Too many arguments for subroutine" unless @_ <= 2;
+ die "Too few arguments for subroutine" unless @_ >= 2;
+ my $left = $_[0];
+ my $right = $_[1];
+ return $left + $right;
+ }
+
+An argument can be ignored by omitting the main part of the name from
+a parameter declaration, leaving just a bare C<$> sigil. For example,
+
+ sub foo ($first, $, $third) {
+ return "first=$first, third=$third";
+ }
+
+Although the ignored argument doesn't go into a variable, it is still
+mandatory for the caller to pass it.
+
+A positional parameter is made optional by giving a default value,
+separated from the parameter name by C<=>:
+
+ sub foo ($left, $right = 0) {
+ return $left + $right;
+ }
+
+The above subroutine may be called with either one or two arguments.
+The default value expression is evaluated when the subroutine is called,
+so it may provide different default values for different calls. It is
+only evaluated if the argument was actually omitted from the call.
+For example,
+
+ my $auto_id = 0;
+ sub foo ($thing, $id = $auto_id++) {
+ print "$thing has ID $id";
+ }
+
+automatically assigns distinct sequential IDs to things for which no
+ID was supplied by the caller. A default value expression may also
+refer to parameters earlier in the signature, making the default for
+one parameter vary according to the earlier parameters. For example,
+
+ sub foo ($first_name, $surname, $nickname = $first_name) {
+ print "$first_name $surname is known as \"$nickname\"";
+ }
+
+An optional parameter can be nameless just like a mandatory parameter.
+For example,
+
+ sub foo ($thing, $ = 1) {
+ print $thing;
+ }