Front page | perl.perl5.porters |
Postings from October 2016
Re: (\@a) = \($x,$y) in non-void context
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
October 19, 2016 08:13
Subject:
Re: (\@a) = \($x,$y) in non-void context
Message ID:
20161019081327.GB3128@iabyn.com
On Wed, Oct 19, 2016 at 04:22:51AM +0200, Aristotle Pagaltzis wrote:
> * Dave Mitchell <davem@iabyn.com> [2016-10-17 10:24]:
> > I've just spotted another issue with list assignment in list context.
> > Does anyone think the third case below is a bug? I think it should
> > output "1:u" like the second case:
> >
> > sub f { print join(':', map $_ // "u", @_), "\n"; }
> >
> > f(($a,$b) = () ); # prints "u:u"
> > f(($a,$b) = (1)); # prints "1:u"
> > f(($a,$b, %h) = (1)); # prints "1"
> >
> > on the principle that the return value of a list assignment is its
> > LHS; i.e. that @a = ((X) = (Y)) should be equivalent to (X) = (Y); @a
> > = (X), where (X) is a list of lvals, like ($a, undef, %h)
>
> Hmm. Probably.
>
> There appears to be only one single mention of what list assignment in
> list context does across the entire documentation, in perlop.pod:
>
> Similarly, a list assignment in list context produces the list of
> lvalues assigned to, and a list assignment in scalar context returns
> the number of elements produced by the expression on the right hand
> side of the assignment.
>
> This reads to me like
>
> ( $foo, $bar, @baz ) = 1..5
>
> is supposed to return the same lvalues as this expression:
>
> ( $foo, $bar, $baz[0], $baz[1], $baz[2] )
>
> Question is, what ought this return?
>
> ( @foo, $bar, @baz ) = 1..3
>
> $foo will be undef after this assignment, so clearly it is “assigned to”
> per the documentation text? And @baz will be cleared as well, however no
> scalar inside it will be assigned to as such. Thus, the list of lvalues
> returned must be this:
>
> ( $foo[0], $foo[1], $foo[2], $bar )
>
> Right? But that seems odd to me too. It is consistent, but is it really
> the intent?
It seems right to me.
There's one further issue I've noticed: undef on the LHS:
sub inc { $_++ for @_ }
inc($a, undef ); # "Modification of a read-only value attempted"
inc(($a, undef) = ($x, $y)); # increments $a and $y
I think that second call to inc should pass ($a, undef) rather than
($a, $y) to inc, and should also die with "Modification of a read-only
value attempted".
--
"Strange women lying in ponds distributing swords is no basis for a system
of government. Supreme executive power derives from a mandate from the
masses, not from some farcical aquatic ceremony."
-- Dennis, "Monty Python and the Holy Grail"
Thread Previous
|
Thread Next