[Swift-devel] typed keys

[Mihael Hategan]

On Sun, 2011-07-24 at 10:42 +0000, Ben Clifford wrote:
> > > introduce runtime type errors: 5+"monkey" (for example) or inability
> > > to add two numbers (5+5 = TYPE ERROR! because those 5s happen to be
> > > Objects not numbers)
> > 
> > You would not be able to use these things in any other context than the
> > places that accept the any type. Such as trace() and whatever else is
> > there that fits, but not "+".
> 
> So should this work? O rather, how liberal does compile time type checking 
> have to be to allow it to work at runtime?
> 
> int a[]; int b[]
> populate(a); populate(b); // with number indices
> for v,k in a {
>  for u,l in b {
>   o[k*1000 + l] = f(u,v)
>  }
> }

Yeah, this should work. It would also allow mixed types:
a[1] = 1; a["b"] = 2;

You won't be able to say:
f(int) {}
foreach v, k in a {
  f(k);
}

But that is fine. If you want that, you can declare a as int[int], and
then you can't have a["b"].

Though this issue is purely hypothetical at this point. It's not the
solution I would favor.

What I favor is auto. We're basically adding the append, so to keep it
separate from everything else we have so far, we would associate it with
the auto type.

> 
> Its something that works at the moment. I don't think this style is used a 
> huge amount but I think it has been done in the past. Constructing string 
> indices by concatenating things is another example of the same, I think.
> 
> With a runtime top-type, the compile time checking needs to be quite 
> loose, I think - here k and l are used numerically, but if you're keeping 
> the discovery of the numericness 'till runtime, then you can't know at 
> compile time.

Again, you wouldn't be able to use an "any" as an int.

> 
> Maybe that is an argument in favour of some compile time inference.
> 

Loosely.