Per S09, we can write in Perl 6:
my int @x;
And the idea is that we get a packed array - conceptually, a single lump
of memory allocated and and storing a bunch of ints contiguously.
Contrast this to:
my Int @x;
Where we get an array of scalar containers, each of which is only
allowed to contain an Int (strictly, something that Int.ACCEPTS(...)
hands back true on).
In the latter case, it's fairly clear how these differ:
@x = 1;
@x := 1;
In the first, we look up the container in slot 0 or the array and assign
a 1 into it. In the second, we bind a 1 directly into the slot. There's
no container any more (so any future assignment attempts will fail, for
With packed arrays, however, I'm less clear what they mean. Since the
point of a packed array is compact storage, there's no chance to
actually have containers. Thus does assignment to a slot in a compact
array ever make sense? There's not a container to look up and store
While I can happily convince myself that:
@x := 1; # works, just sticks 1 into the appropriate location
@x = 1; # dies, can't assign when there's no container
Actually makes sense, I can also somewhat see users not liking it. So my
1) What semantics would users expect? Is it OK to say "no, you can't
assign" in this case?
2) If proposing that both should work, what, roughly, would that look
like at an implementation level?
When answering (2), consider that:
@x = 42;
Currently really means:
That is, we really do look up the container and then perform an
operation in it. So if you de-sugar it all, it's kinda like:
So just saying "oh, just given assignment semantics like binding ones"
is not so simple, since it'd seem that we do not get anything we could
call .STORE on back from @x from a natively typed array.
Any thoughts? (Same questions/answers apply for natively typed
attributes in objects, or at least I'd be very surprised if they are