From @lizmat

Slicing handles ranges differently from lists, even if the range is not infinite.

my @​a;
say @​a[0,1].perl; # (Any,Any)
say @​a[^2].perl; # ()

This becomes even more troublesome when used as a left value​:

@​a[0,1] = 42,43 # (42,43)
@​a[^2] = 42,43 # ()

This I find to be a real bug.

The problems are really cause by the fact that slices create a Parcel is rw, and ranges look at the @​a.gimme information to fill in entries. So @​a[^2] creates an empty Parcel, in which into the values are assigned into oblivion, like any extra values would.

From @pmichaud

On Thu Apr 16 09​:50​:05 2015, elizabeth wrote​:

Slicing handles ranges differently from lists, even if the range is
not infinite.
[...]
This I find to be a real bug.

It's not a rakudobug -- rakudo is following S09 here. Quoting S09​:

  For subscripts containing range or sequence iterators extending beyond
  the end of autoextending arrays, the range is truncated to the actual
  current size of the array rather than the declared size of that dimension.
  It is allowed for such a range to start one after the end, so that

  @​array[0..*]

  merely returns C<()> if C<@​array> happens to be empty.

So, first file this as a design change request (http://github.com/perl6/specs/issues) and then we can update Rakudo to match.

Pm

The RT System itself - Status changed from 'new' to 'open'

From @coke

On Thu Apr 16 09​:50​:05 2015, elizabeth wrote​:

Slicing handles ranges differently from lists, even if the range is
not infinite.

my @​a;
say @​a[0,1].perl; # (Any,Any)
say @​a[^2].perl; # ()

This becomes even more troublesome when used as a left value​:

@​a[0,1] = 42,43 # (42,43)
@​a[^2] = 42,43 # ()

This I find to be a real bug.

The problems are really cause by the fact that slices create a Parcel
is rw, and ranges look at the @​a.gimme information to fill in entries.
So @​a[^2] creates an empty Parcel, in which into the values are
assigned into oblivion, like any extra values would.

No change to this behavior in GLR for the first bit...

15​:31 < [Coke]> m​: my @​a; say @​a[0,1].perl; say @​a[^2].perl;
15​:31 < GLRelia> rakudo-moar a11e8f​: OUTPUT«(Any, Any)␤()␤»
15​:31 <+camelia> rakudo-moar a7c845​: OUTPUT«(Any, Any)␤()␤»

Second bit looks like the behavior changed in camelia slightly, but is also unchanged in GLR.

15​:35 < [Coke]> m​: my @​a; my @​b; @​a[0,1] = 42,43; say @​a.perl; @​b[^2] = 42,43;
  say @​b.perl;
15​:35 < GLRelia> rakudo-moar a11e8f​: OUTPUT«[42, 43]␤[42, 43]␤»
15​:35 <+camelia> rakudo-moar a7c845​: OUTPUT«[42, 43]<>␤[42, 43]<>␤»

--
Will "Coke" Coleda

From @jnthn

On Thu Apr 16 09​:50​:05 2015, elizabeth wrote​:

Slicing handles ranges differently from lists, even if the range is
not infinite.

my @​a;
say @​a[0,1].perl; # (Any,Any)
say @​a[^2].perl; # ()

This becomes even more troublesome when used as a left value​:

@​a[0,1] = 42,43 # (42,43)
@​a[^2] = 42,43 # ()

This I find to be a real bug.

The problems are really cause by the fact that slices create a Parcel
is rw, and ranges look at the @​a.gimme information to fill in entries.
So @​a[^2] creates an empty Parcel, in which into the values are
assigned into oblivion, like any extra values would.

We've now changed it so that @​a[^2] will be the same as @​a[0,1], to avoid this common gotcha. Infinite ranges still auto-truncate. The existing auto-truncating behavior is still available as @​a[lazy ^2].

A bunch of tests were updated, and there's an explicit test for this case in S03-operators/assign.t.

@jnthn - Status changed from 'open' to 'resolved'