Juerd wrote:
If assigning a ref to a hash uses the hashref's elements, then the same
is to be expected for an array.
Same feeling here. But I would let the array concede.
Because this behaviour is unwanted for
arrays (because you then can't assign a single arrayref anymore without
doubling the square brackets, communicating an entirely wrong thing),
You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.
hashes have to concede as well, even though %a = $href may not make
sense.
I would treat it just the same as a literal hashref build with
{ => } because this should be what the dispatch system sees anyway.
E.g.
%h;
sub assign { my $href = { a => 1, b => 2}; %h = $href }
assign;
should be the same as
%h = { a => 1, b => 2 };
I recall having read something about , being "listfix", not infix. The
same would be true for Y and | and & and ^.
I can't find that in the archives. But it is a nice abbreviation for
&infix:<,> ( ... ) is assoc(list). Could/should the same be done
as chainfix, leftfix and rightfix? Or asterfix, idfix, truebafix, ... :))
This last joke might work for Germans only.
--
TSa (Thomas Sandlaß)
