The documentation that Eily references says this:

NOTE: The behaviour of a my, state, or our modified with a statement modifier conditional or loop construct (for example, my $x if ...) is undefined. The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

The example it gives is:

my $x if ...
[download]

The example you give is:

my $var if $test;
[download]

I see nothing that invalidates Eily's example of:

my $var = 1 if $test;
[download]

Another important point from that is: "Future versions of perl might do something different from the version of perl you try it out on."

I don't think showing us the results of just two tests is particularly meaningful.

[While it's probably a moot point, your second one-liner (with my $c = 1 if 0) doesn't indicate whether $c's value is a zero-length string or undef.]

Hi Ken,

Thank you for your answer and I have usually the highest regard for your posts (and I upvoted your answer even though I still disagree with it, because I think it is well explained). To set the record straight, I am not trying to invalidate Eily's example, far from that, I am just trying to understand what exactly is undefined behavior here. And I am still not convinced at all that:

my $var if $test;
[download]

and

my $var = 1 if $test;
[download]

are equivalent in terms of the behavior being defined or not. These are two quite different types of statements. Assuming just one second, only for the sake of argument, they had both a defined behavior, I would still consider the first one as almost entirely useless (and deserving to be undefined), and the second one as making some sense (although lacking clarity, to say the least). Therefore, if the author of the documentation meant to say that my $var = 1 if $test; also has undefined behavior, then I would submit that this should probably be added to the documentation, because having someone using this second type of construct is much more likely than than the first one.

Again, I am not saying that Eily is wrong, I just don't know and I truly would like to know. While I usually would probably not use something like:

my $var = 1 if $test;
[download]

I would really not swear that I have never used something like:

my $value = $1 if $foo =~ /^\w+(\d+)/;
do_something($value) if defined $value;
[download]

And, as far as I can say, I would expect this to work fine.

Concerning the one-liners, I agree that they were very short examples I added at the last minute to my post, this is an improved version of them:

$ perl -Mstrict -Mwarnings -e  ' my $c = 1 if 1; print $c;'
1
~
$ perl -Mstrict -Mwarnings -e  ' my $c if 1; print $c;'
Use of uninitialized value $c in print at -e line 1.
[download]

I am not saying that observed behavior is describing the Perl standard, but since there is no real Perl 5 standard, in a certain way, only the compiler can tell us what to think when the documentation is ambiguous. And I think the documentation is definitely ambiguous in that specific case. Having said that, I perfectly understand the warning: "Future versions of perl might do something different..." Just not sure that it applies to something like:

my $var = 1 if $test;
[download]

It may be that you're reading more into the given example than is intended in the documentation. Examples tend to be short and to the point: complex examples can often obscure the main idea that the example is intending to convey. "my $x if ..." would be one of the shortest examples that showed a lexical declaration with a statement modifier.

"... my, state, or our ..." are all keywords that introduce a lexical declaration. There's nothing in the documentation that says anything about how those keywords might be used: it mentions no restrictions or exemptions. Just because the example only shows "my $x", I see nothing that suggests more complex examples would behave any differently (with respect to producing in an undefined result which should not be relied upon). All of these would be equally valid examples but tend to (increasingly) hide the point being made (and might even suggest exclusion of simpler examples):

my ($x) if ...
my $x = 1 if ...
my ($x, $y) = (1, 2) if ...
my ($x, $y, $z) = (split /\s+/ => $spaced_tokens)[3 .. 5] if ...
[download]

Similarly, "... modified with a statement modifier conditional or loop construct ..." mentions no restrictions or exemptions. The example uses "if"; however, there's nothing to suggest that any of the other modifiers (unless, while, until, for, foreach or when) would behave any differently (with respect to producing in an undefined result which should not be relied upon).

For what it's worth, I played around with the OP code a bit when it was first posted. In one test, I added a check for whether $test1 was defined after "my $test1 = ... if ...;". In the first call to test(), $test1 was undefined; in the second call it was defined:

$test1 is not defined.
Use of uninitialized value $test1 in concatenation (.) or string at ./
+pm_example.pl line 13.
test1 after hash assignment:        ''
i = 0    test1 after defaulting to i:    '0'
$test1 is defined.
test1 after hash assignment:        '0'
i = 1    test1 after defaulting to i:    '0'
[download]

That looks like exactly the unpredictable results described in: "The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it."

-- Ken

when the perl5-porters update the documentation, and say "don't do that its undefined", then they mean it don't do that even if does something you expect 80% of the time :)

For example see Re^3: question 1st - undefined behaviour (perlop)

I'm sure there is even more similar nodes/posts of wisdom to be found for Perl::Critic::Policy::Variables::ProhibitConditionalDeclarations ... trust the documentation

update:
my $cache = undef if undef;
Re^4: Managing capture
"my $p = value if condition()" as bad|deprecated as "my $p if 0" (Naughty indeed)
This Week on p5p 2000/05/21 my $x if 0; Trick
my $x if 0; Trick my @array = () if 0;
state variables, first draft - nntp.perl.org
state

my with postfix if is the singular problem, regardless of any assignment, present or absent.

My understanding, from reading aforesaid document, is that my $var if $test; is undefined.

But the cited doc in Re: postfix syntax enlightenment sez "NOTE: The behaviour of ... is undefined.", clearly, I think, referring to behavior (or behaviour, if you will) rather than to the state of the lexical being undef (if I correctly understand your understanding). (The link is to 5.18.2 docs, but my local 5.10.1 docs say essentially the same, but without reference to state or our.)