Re: Arrays: Default Values

[Michael Lazzaro]

OK, I think we agree that 'default' refers to what to put in the 'holes' of an array (or hash, but that's a separate discussion.) When you overlay a real hash on top of your default values, the default values "show through the holes". So now we just have to define what "holes" are.

An assertion: The 'is default' property overrides the default 'empty' value of the given underlying type. For a normal array of scalars, that 'empty' value is C<undef>. But some scalar types can be set to undef, and some can't:

my @a; # 'empty' value of a scalar is undef
my int @a_int; # 'empty' value of an 'int' is 0
my str @a_str; # 'empty' value of a 'str' is ''

my Int @a_Int; # 'empty' value of an 'Int' is undef (right?)
my Str @a_Str; # 'empty' value of a 'Str' is undef (right?)

So C<is default <def>> is defining the value to use as the 'empty value' of the _underlying cell type_.

There are two credible choices, AFAICT:

Solution 1: If you attempt to SET a cell to it's 'empty value', it will be set to it's default:

my int @a is default(5); #
@a[5] = 0; # actually sets it to it's 'empty value', 5
@a[5] = undef; # autocnv to 0, + warning, still sets to 5

my Int @a is default(5); # NOTE difference in type!
@a[5] = 0; # THIS really does set it to 0
@a[5] = undef; # and this sets it to 5

So you can't set something to its type's own empty value, because it will, by definition, thereafter return it's "overloaded" empty value, <def>.


Solution 2: _ANY_ other solution would require the introduction of 'fake empty' and 'really empty', and require arrays to keep track of the difference.

my Int @a is default(5);

@a[3] = 3; # there are now 4 items in the array
@a[2]; # was autoset to undef, so returns 5
@a[4]; # doesn't exist, so returns 5

@a[2] = undef; # well, it's still undef, but now mark it
# as a 'real' undef, so don't return 5.

This is essentially adding another layer of defined-ness on each cell, and therefore requires an additional flag be kept & checked for each array element. While this is certainly a possibility, I worry about the complexity it introduces.

-----

In spite of the perhaps surprising nature of solution 1, I think it is probably the more correct solution, if you really insist on putting a default value on a primitive-typed array. As it points out, you can still get both behaviors, simply by choosing int vs. Int, str vs. Str, etc.

If you want behavior more complicated than that, I think you probably should be creating a custom Array subclass.

Comments?

MikeL