Your intent is not clear. What do you mean by “returning a hash”? You can't do that, per se. Did you mean to return a hash ref or a list of key/value pairs that can be assigned to a hash?

In either case the hash slice is a red herring. Quoth perlop under Assignment Operators:

[…] a list assignment in list context produces the list of lvalues assigned to, […]

which matches the exact behaviour you described.

If you want to return a hash ref you're going about this wrong. That code would be

sub build_hash {
    my %return;
    @return{@keys} = @values;
    \%return;
}
[download]

Returning a list of key/value pairs requires more list-fu:

sub build_hash {
    ( @keys, @_ )[ map { $_, $_ + @keys } 0 .. $#keys ];
}
[download]

Makeshifts last the longest.

My intent was to return a list of key-value pairs, as in the code sample - and I'm not sure I agree with your doc-quote

… a list assignment in list context produces the list of lvalues assigned to, …

Isnt the list assigned to the hash(or list of key/value pairs) %return ?
Isnt the list assigned to on the left hand side of the '=' ?
In the second code samples case that would be (a,1,b,2,c,3,d,4), yes?

The list assigned _from_ is what I'm seeing returned..

Apart from that the list-fu is a neat trick, but perhaps the explicit return is more appropriate, as discussed later in this thread, or a better understanding of when to use return...

...it is better to be approximately right than precisely wrong. - Warren Buffet

You misunderstand.

No, the list assigned to is not %return. You are taking a hash slice. The hash as a whole is nowhere to be seen in this assignment. I get the feeling that you haven't understood exactly what taking a slice does.

Yes, the list assigned to is on the left hand of the assignment operator.

I'm not sure which second code sample you are talking about.

You are not seeing the list assigned from. You are seeing what the list you assigned to evaluates to, which in this case is 1, 2, 3, 4. The distinction is subtle and may be confusing but you are indeed getting the list assigned to:

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;

my %return;
my @value = qw( foo bar baz quux );

$_ = uc $_
    for @return{ qw( a b c d ) } = @value;

print Dumper( \%return ), Dumper( \@value );

=begin output
$VAR1 = {
          'c' => 'BAZ',
          'a' => 'FOO',
          'b' => 'BAR',
          'd' => 'QUUX'
        };
$VAR1 = [
          'foo',
          'bar',
          'baz',
          'quux'
        ];
[download]

As you can see, the $_ = uc $_ assignment changed the values in the hash. If you were getting the list assigned from, it would have changed the values in @value.

Makeshifts last the longest.

From perldoc perlsub: The return value of a subroutine is the value of the last expression evaluated by that sub...

The value of an assignment operation in list context is generally the value(s) being assigned. Thus, when you're assigning a list to something, that's the value of the assignment and therefore that's the return value of the subroutine.

Thanx Ovid, now I guess I'll have to research what circumstances are not covered by the "generally"
....starts shuffling through rudely stacked piles of perldoc covering his desk...

...it is better to be approximately right than precisely wrong. - Warren Buffet

Or just a "%return" - return is optional. Either way, make the return value explicit, rather than relying on a complex operation to do it, whether you make the fact you're returning explicit or not.

(I did some benchmarks a while back which surprised me to find out that "return %hash" was actually slower than "%hash" and falling out the bottom of the function...)

You surprised me with this, but:

            Rate return no ret
return 4682554/s     --   -30%
no ret 6642457/s    42%     --
[download]

Is what i got from:

use Benchmark qw( cmpthese );

my %hash = (1, 2, 4, 6, 43, 32, 5, 6, 6, 43, 3, 54, 5, 1);

cmpthese(0, {
    'return' => sub { return \%hash },
    'no ret' => sub { \%hash },
});
[download]

Depends. I often implicitly return the result of an operation that would obviously be useless in void context, as in

sub as_string {
    my $self = shift;
    join '-', $self->date;
}
[download]

or the like.

Makeshifts last the longest.

We actually have it as a coding standard. The explicit return is required. It's obvious to some, but the time spent by a beginner or intermeddiate programmer thinking about exactly what is being returned can offset the shortcut. We have quite a lot of perl code, so we often have beginner level people looking at stuff and implicit return values really slow them down.

The performance penalty is interesting. I wasn't aware of that. Might add up if you had a sub that is called many times in your program.

so we often have beginner level people looking at stuff and implicit return values really slow them down

It would be faster to take the 15 minutes to teach each of them about Perl's very simple return policy ("last expression evaluated is always the return value") than to require every coder in the world to make up for their lack of training.

Even if you could establish policy for newly written code at your organization, these coders will always be looking at code from the CPAN or from consultants that clearly are not going to put in all of your handholding.

I don't want to suggest that coding standards are categorically silly, but don't try to make Perl look like another language in the standard. Lack of the "return" keyword is both idiomatic and commonplace.

It's a bit like demanding that every sharp corner in the workplace be covered with Nerf foam, just because there are some people who walk around with their eyes shut. No, it'd be simpler to teach them to watch where they are going.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I tend to agree with you, except for certain situations. I will get rid of the return when my function is a one-liner, along the lines of:

sub foo { (+shift)->foo_bar( 'foo', @_ ) }
sub bar { (+shift)->foo_bar( 'foo', @_ ) }

sub foo_bar {
    my $self = shift;
    my ($type, @args) = @_;

    # Do stuff here
}

sub unique { my %x; @x{@_} = @_; values %x }

sub stringify { join '-', $_[0]->date }
[download]

If my function gets to more than 80 characters, including the subroutine name, and/or it isn't a drop-in replacement for where it's called, then I use more than one line, don't directly access @_, and use an explicit return.

(I access @_ for aliasing-type stuff as well, but I'll do it here for brevity.)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.