Aaah, things are clearer now - the "sub" constraint seems robust and
rational to me (see also http://www.perlmonks.org/?node_id=477891).
> Is the current documentation actually *wrong*. In that the
> unspecified-ness
> propagates? ie the documentation says that this wantarray is specified:
>
> $ perl -lwe 'sub a {print "=", wantarray}; BEGIN {a}'
> =
> But I think that actually it's not.
So I think that we can safely say that it's not, even if it could actually
be. The whole point of unspecifiedness is that you should not rely on such
a behaviour, so to be on the safe side I would say that wantarray is not
specified in this scenario.
This is what I tried to put into my proposal below:
------- CUT HERE -----------
wantarray()'s result is only specified within subroutines/methods
defined using the C<sub> keyword, with the only exception of
implicit calls to DESTROY. Thus, wantarray is unspecified
in a BEGIN, CHECK, INIT and END block (they're not "regular" subs) and
when using C<do> in whatever form (also not a sub, although it
returns the value of the last statement).
Note that "unspecified" means that it could work as you would
expect/desire now, but this is not guaranteed for the future
and you should not rely on it.
Also note that wantarray()'s result is unspecified when you call
your subroutine from unspecified contexts. So, if you have this:
sub foo {
return qw( Hello world! ) if wantarray;
return 'Howdy!' if defined wantarray;
die "CONSIDER ME!!!";
}
wantarray() is generally specified, except when you call the sub like
this:
BEGIN { foo }
Being the last statement in the block, foo "inherits" the calling
context from BEGIN, which is unspecified as said before.
------- CUT HERE -----------
Best regards,
Flavio Poletti.
