Arrays: is computed

[Michael Lazzaro]

For C<is computed> arrays, things get more complicated. Since there are no true 'holes' in a primitive-typed array, the correct behavior there would seem to be to autofill the array using the computed values.

For example, an empty array:

my int @a is computed { $^index ** 2 }

@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)

Now setting an element:

@a[4] = 0; # (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2]; # 4
@a[3]; # 9
@a[4]; # 0
@a[5]; # 25 (still doesn't exist, is computed)

@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant it)


Again, note the dubious behavior of doing a C<shift> or other manipulation on any C<is computed> array. The autofilled portion would shift, but the computed portion would not:

my int @a is computed { $^index ** 2 }

# at first, @a is entirely computed, (0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a; # (1,4,9,0) + (16,25,...)
shift @a; # (4,9,0) + (9,16,25,...)
shift @a; # (9,0) + (4,9,16,25,...)
shift @a; # (0) + (1,4,9,16,25,...)
shift @a; # () + (0,1,4,9,16,25,...)

Not saying that's wrong. Just very, very wacky. And yes, it's fixable if every array has an "offset" number that's always updated to mark how far the array has been shifted/unshifted from it's starting point. But I'm not suggesting that. Really.

MikeL