one large indistinguishable list.
If no C<return> is found and if the last statement is an expression, its
-value is returned. If the last statement is a loop control structure
-like a C<foreach> or a C<while>, the returned value is unspecified. The
+value is returned. If the last statement is a loop control structure
+like a C<foreach> or a C<while>, the returned value is unspecified. The
empty sub returns the empty list.
X<subroutine, return value> X<return value> X<return>
return($x * __SUB__->( $x - 1 ) );
};
-The behaviour of C<__SUB__> within a regex code block (such as C</(?{...})/>)
+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
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
+same way. The following is a list of some subroutines that currently do
special, pre-defined things.
=over
X<state> X<state variable> X<static> X<variable, persistent> X<variable, static> X<closure>
There are two ways to build persistent private variables in Perl 5.10.
-First, you can simply use the C<state> feature. Or, you can use closures,
+First, you can simply use the C<state> feature. Or, you can use closures,
if you want to stay compatible with releases older than 5.10.
=head3 Persistent variables via state()
B<WARNING>: Localization of tied arrays and hashes does not currently
work as described.
This will be fixed in a future release of Perl; in the meantime, avoid
-code that relies on any particular behaviour of localising tied arrays
+code that relies on any particular behavior of localising tied arrays
or hashes (localising individual elements is still okay).
See L<perl58delta/"Localising Tied Arrays and Hashes Is Broken"> for more
details.
It's also worth taking a moment to explain what happens when you
C<local>ize a member of a composite type (i.e. an array or hash element).
-In this case, the element is C<local>ized I<by name>. This means that
+In this case, the element is C<local>ized I<by name>. This means that
when the scope of the C<local()> ends, the saved value will be
restored to the hash element whose key was named in the C<local()>, or
the array element whose index was named in the C<local()>. If that
You can use the C<delete local $array[$idx]> and C<delete local $hash{key}>
constructs to delete a composite type entry for the current block and restore
-it when it ends. They return the array/hash value before the localization,
+it when it ends. They return the array/hash value before the localization,
which means that they are respectively equivalent to
do {
$val
}
-except that for those the C<local> is scoped to the C<do> block. Slices are
+except that for those the C<local> is
+scoped to the C<do> block. Slices are
also accepted.
my %hash = (
The scalar/list context for the subroutine and for the right-hand
side of assignment is determined as if the subroutine call is replaced
-by a scalar. For example, consider:
+by a scalar. For example, consider:
data(2,3) = get_data(3,4);
all the subroutines are called in a list context.
Lvalue subroutines are convenient, but you have to keep in mind that,
-when used with objects, they may violate encapsulation. A normal
+when used with objects, they may violate encapsulation. A normal
mutator can check the supplied argument before setting the attribute
-it is protecting, an lvalue subroutine cannot. If you require any
+it is protecting, an lvalue subroutine cannot. If you require any
special processing when storing and retrieving the values, consider
using the CPAN module Sentinel or something similar.
that must start with that character (optionally preceded by C<my>,
C<our> or C<local>), with the exception of C<$>, which will
accept any scalar lvalue expression, such as C<$foo = 7> or
-C<< my_function()->[0] >>. The value passed as part of C<@_> will be a
+C<< my_function()->[0] >>. The value passed as part of C<@_> will be a
reference to the actual argument given in the subroutine call,
obtained by applying C<\> to that argument.
You can use the C<\[]> backslash group notation to specify more than one
-allowed argument type. For example:
+allowed argument type. For example:
sub myref (\[$@%&*])
sub N () { int(OPT_BAZ) / 3 }
sub FOO_SET () { 1 if FLAG_MASK & FLAG_FOO }
+ sub FOO_SET2 () { if (FLAG_MASK & FLAG_FOO) { 1 } }
-Be aware that these will not be inlined; as they contain inner scopes,
-the constant folding doesn't reduce them to a single constant:
-
- sub foo_set () { if (FLAG_MASK & FLAG_FOO) { 1 } }
+(Be aware that the last example was not always inlined in Perl 5.20 and
+earlier, which did not behave consistently with subroutines containing
+inner scopes.) You can countermand inlining by using an explicit
+C<return>:
sub baz_val () {
if (OPT_BAZ) {
return 42;
}
}
+ sub bonk_val () { return 12345 }
As alluded to earlier you can also declare inlined subs dynamically at
BEGIN time if their body consists of a lexically-scoped scalar which
-has no other references. Only the first example here will be inlined:
+has no other references. Only the first example here will be inlined:
BEGIN {
my $var = 1;
}
print RT_79908(); # prints 79907
+As of Perl 5.22, this buggy behavior, while preserved for backward
+compatibility, is detected and emits a deprecation warning. If you want
+the subroutine to be inlined (with no warning), make sure the variable is
+not used in a context where it could be modified aside from where it is
+declared.
+
+ # Fine, no warning
+ BEGIN {
+ my $x = 54321;
+ *INLINED = sub () { $x };
+ }
+ # Warns. Future Perl versions will stop inlining it.
+ BEGIN {
+ my $x;
+ $x = 54321;
+ *ALSO_INLINED = sub () { $x };
+ }
+
If you really want a subroutine with a C<()> prototype that returns a
lexical variable you can easily force it to not be inlined by adding
an explicit C<return>:
print RT_79908(); # prints 79908
The easiest way to tell if a subroutine was inlined is by using
-L<B::Deparse>, consider this example of two subroutines returning
+L<B::Deparse>. Consider this example of two subroutines returning
C<1>, one with a C<()> prototype causing it to be inlined, and one
without (with deparse output truncated for clarity):
};
If you redefine a subroutine that was eligible for inlining, you'll
-get a warning by default. You can use this warning to tell whether or
+get a warning by default. You can use this warning to tell whether or
not a particular subroutine is considered inlinable, since it's
different than the warning for overriding non-inlined subroutines:
you need to be able to redefine the subroutine, you need to ensure
that it isn't inlined, either by dropping the C<()> prototype (which
changes calling semantics, so beware) or by thwarting the inlining
-mechanism in some other way, e.g. by adding an explicit C<return>:
+mechanism in some other way, e.g. by adding an explicit C<return>, as
+mentioned above:
sub not_inlined () { return 23 }
C<glob>, the C<< <*> >> glob operator is overridden as well.
In a similar fashion, overriding the C<readline> function also overrides
-the equivalent I/O operator C<< <FILEHANDLE> >>. Also, overriding
+the equivalent I/O operator C<< <FILEHANDLE> >>. Also, overriding
C<readpipe> also overrides the operators C<``> and C<qx//>.
Finally, some built-ins (e.g. C<exists> or C<grep>) can't be overridden.
https://perl5.git.perl.org / perl5.git / blobdiff