Then don't write it that way:

foreach my $address (@email_addresses) {
    my $is_valid = $address =~ /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/;

    if ($is_valid) {
        ....
    }
}
[download]

Seriously, if you're writing code for public consumption and think, "Gee, I hope who's ever reading this can understand it," then rewrite it so you're sure they'll be able to understand it, or comment it, or do both.

I just grepped my source repository to see where I'd written that and I couldn't find it. The general case I'd thought of where it was annoying or inconvenient to the narrative to give the topicalized variable a name. I can't find an example (though I did just find a code-typo in Switch.pm where ~= was said instead of =~).

for ( ... )
{
    $foo = /.../;
}
[download]

It's *almost never* annoying or inconvenient to the narrative to give topicalized variables names.

The loop is the discussion and the alias variable is what's being talked about. It's the topic--the subject--and it has a name, even if you don't feel like giving it one. And using "for" when you really mean "foreach" element in some list doesn't help anyone either (again, when the code's for public consumption, not when it's just for you.)

Well, I not only wouldn't use explicit loop variables when I can resort to the singular pronoun (or even better, when I can omit it) but I would also try to avoid unnecessary assignments ;-)

foreach (@email_addresses) {
    if ( /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/ ) {
        ....
    }
}
[download]

This is IMHO more legible, as long as your public is fluent in Perl, or just knows the basics.
The only context where I would use your code is a Perl class, but just to show immediately after how to shorten that code and make it more legible (confess, you are a teacher! ;-)

Cheers,
Emanuele.

Emazep, it was just an example; Diotalevi and I were talking about a situation in which the assignment is practical for some reason (like if you're calling m//g in scalar context), not one where you can get away with sticking m// in a conditional by itself. (Who on earth would store away the result unless they needed for something later on, anyway?)

My point was that if you have an assignment like "$var = /pattern/", then name the variables and use the binding operator explicitly so it's completely unambiguous: "$pos = $string =~ /pattern/g".

In real life I would have written that validity checking code like this:

foreach my $address (@email_addresses) {
    return unless ($address =~ /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/);

    # proceed normally...
[download]

As long as $var was named something like $count, or possibly $matched, or the context itself gave this information then I would say its fine. If $var was actually $str or the like I would probably say it was a bug. If it said ($var)=/$pattern/ it would almost certainly be fine regardless.