Hmm, I think you might have got caught up in a side street on this one. For instance for first example _shouldn't_ be written that way. When people say "dont use map in void context" they say it for good reasons.

@out_list=@in_list;
s/foo(.*?)bar/$1 baz/ for @in_list;
[download]

Update:
I like japhys version, and I'd probably use it myself, but I can see some people saying that the above version is more understandable. japhy++

Your second method leaves a lot to be desired (its unusable for a variety of reasons), and your third version is workable, although i'd probably write it

@out_list = map {local $_=$_; s/foo(.*?)bar/$1 baz/; $_ } @in_list;
[download]

Anyway, heres a sub so you can write it the way that feels comfortable

sub ro_map (&@){
    my $sub=shift;
      my @return;
      foreach (@_) {
        local $_=$_;
        push @return,$sub->();
      }
      @return
}
my @out=ro_map{s/x/y/g}@in;
print "original: @in\n";
print "changed : @out\n";
[download]

One could argue that this dual result from the mapped code block -- doing in-place editing of the input list and also returning the edited list -- seems to be overdoing it, or is somewhat redundant.

I dont think you would get far with this argument. Howabout this:

# lc the filenames and create a set of filespecs from them.
my @filespecs=map{ $_=lc($_); File::Spec->joinpath($path,$_) } @files;
[download]

HTH

Now on to read the other comments. :-)

Yves / DeMerphq
---
Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)