in reply to hash slice ? No thanks, I'm about to return...

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; }

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

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

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: hash slice ? No thanks, I'm about to return...
by leriksen (Curate) on Feb 20, 2005 at 00:35 UTC
    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' ];

      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.

        I had considered trying to take this off-line, but if I am still confused, maybe others are.

        My question is, why does the list assigned to not include the keys as well ?

        And perhaps can you give an example that doesn't use $_ with all its aliasing behaviour just adding to the noise.

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