On Tue, 04 Jul 2017 07:20:50 -0700, elizabeth wrote:
> > Hm. Wouldn't that make behavior of Lists and Arrays different?
>
> No, because Lists are supposed to be immutable wrt to the number of
> elements.
Yes, but that doesn't mean the user of the list necessarily knows or has to
know how many elements the list has, to look up an element by index, without
things exploding.
> generate a Failure on out of bounds value
IMO that's the wrong approach and the current behaviour of returning Nil is
most desirable. Consider this code:
sub do-stuff (@args) {
say @args[0] + 1;
}
do-stuff [];
do-stuff ();
If you Fatalise past-end .AT-POS on Lists that sub will now work fine with
Arrays, but crash with Lists. So as a consumer of `@args` Iterable, I'm now
faced with two potential behaviours and have to account for Exceptions.
Currently, the code will also produce a warning, as do many things that consume
a Nil where Nil doesn't really belong. IMO that's a good-enough warning for the
inadvertent out-of-bounds access.
By adding the Failure, we also end up with another inconsistency that `my ($a,
$b) = @list` would work and assign Nil to `$b` when `@list` has just one
element, but `my ($a, $b) = @list[0,1]` would assign a Failure to it. Lastly,
we'd have `@list[0,1]` return a list with 1 value and 1 Failure in it (call
.elems on it and the Failure's silently gone).
So, IMO, yes, we could change "0..^Inf" to tell number of actual elements, but
that error is fundamentally different from trying to access past List's end,
because you can NEVER access element at index -1, yet you can access index N,
and we should leave the "return Nil" behaviour as is and not deviate from Array
behaviour.
