Yes, it is "just as bad" in my book, worse actually. The "my ... if 0" is at least clear in that it is intentional in misusing a misfeature in order to get a "static" variable (in C terms) similar to the new "state" variables.

But "my ... if ..." is worse in that it is either misusing this misfeature in a more complicated way (which makes it a worse misuse in my book), or it is not intended to use the misfeature in which case it is a likely source of bugs (which is worse than misusing a misfeature in my book).

So you should replace "my $foo= ... if ...;" with "my $foo; $foo= ... if ...;" and very carefully determine (if you are smart or lucky, by simply running your comprehensive test suite) whether the misfeature was desired.

In the unlikely event that the misfeature was desired, then you should replace the code with something more complex, such as the following code that does not require 5.010:

# Rarely, you should replace:

sub foo
{
    # ...
    my $bar= init() if condition();
    # ...
}

# With:

BEGIN {
    my $prevBar;

    sub foo
    {
        # ...
        my $bar= $prevBar;
        $prevBar= $bar= init()
            if  condition();
        # ...
    }
}
[download]

Hopefully, you will follow that with some refactoring which will make the code clearer. Bah, that puts too little emphasis on the more likely correct replacement so let me repeat it below more verbosely.

# Usually, you should replace:

    my $bar= init() if condition();

# With:

    my $bar;
    $bar= init()
        if  condition();

# or even:

    my $bar= condition() ? init() : undef;
[download]

From what i can tell, the occurrences were not being used for any kind of magic or misfeatures. They are used to just get a value to assign from a method when some related variable(s) are usable (object passes defined test, variable is true or defined, etc).

As for your proposed syntax near the end of your post, well, my changes are also on the same lines.

Thanks ikegami.

Few hours ago I failed to find a reference as I focused on the deprecated warning. Now I see that it is clearly stated in perlsyn near the end of Statement Modifiers section. I suppose that is an indication to re-read the fine manuals.

I've had it come it in code reviews. In order to effect the minimum amount of changes to prevent the problem, I use the following change:

my $p = $q if condition();
# becomes
my $p = condition() ? $q : undef;
[download]

This avoids introducing a second statement, such as instantiating and then assigning:

For the risk in this latter piece of code is that someone might "helpfully" refactor it back again. The ternary operator forces people to think about both sides of the condition.