[Swift-devel] typed keys

[Mihael Hategan]

On Sat, 2011-07-23 at 23:07 +0530, Yadu Nand wrote:
> > There are a few solutions I can think of:
> > 1. Have a universal type, which is what is used when saying array[].
> > That would allow both array[0] = value, array["key"] = value, and array
> > << value. Also allow auto-increment on array[string]. This will keep
> > compatibility with existing scripts (i.e. allowing int keys when there
> > is no explicit key type in the declaration). This would require us to be
> > clear about when and how the universal/top type can be used.
> Are you suggesting something like an object type ? But wouldn't that
> reduce the strongly-typed 'ness of the language ?

Yes. Something like Object in Java. And not necessarily: "Luca
Cardelli's article Typeful Programming describes strong typing simply as
the absence of unchecked run-time type
errors." (http://en.wikipedia.org/wiki/Strong_typing#Interpretation)

Though I don't think the language allows run-time type errors to happen.

The only issue is that we need predictability of the ordering of array
elements when passed to an app. For example "echo array" should always
produce the list of array elements according to a well defined ordering
on the keys. This is easier to do when the keys are of the same type,
but I suppose it can also be done with mixed types if there is an
ordering on the types themselves.

> 
> > 2. Have an auto-increment key type and only allow << on those. I believe
> > that Ben mentioned something like this.
> Why do we need a separate type ? Or, are you saying the user would say
> array[int]["auto-inc"] and we'd internally use strings ?

Something like that. I went with strings for now, but I think this is
the cleanest solution in the end. Though I'm a bit fuzzy. This would
also mean that we wouldn't allow a["somekey"] = v, and the only way to
use such an array would be with keys of some black-box value of type
"autokey". Which may be an advantage, since allowing manual keying of
auto arrays may generate involuntary collisions (if somebody decides to
do use a key that's the same as an auto-generated key).

Ben, Ian?

> 
> > 3. Require that arrays supporting << be array[string] and keep array[]
> > as array[int].
> This is probably the simplest way to go about it. I could perhaps add
> some extra checks to ensure that the subscript has been declared as
> string.

I added the checks.

> 
> This is probably a language decision which I shouldn't influence
> because I tend to lean towards ease of implementation :)
> 

Well, maybe. The way I see it is that sacrifices in the ease of
implementation may be worth making if they make the user's life better.
After all, in theory, the implementation is re-usable, while users
writing programs is something that happens over and over. In other
words, if you use a tool a lot, you might as well make it a good tool.