Future-prove collections::VecMap

[tbu-]

Since VecMap might want to have key type parameter at some point, add a key
type parameter now, so that code running today will still run when actual
generalization of the key is added.

The trait VecMapKey should really be private, but this is blocked by the fact
that you cannot export a struct, function or trait implementation with one of
the type parameters being bound by a private trait.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[tbu-]

Old PR: #20150

[tbu-]

@gankro Have you thought about this?

@aturon We're now in alpha, could we reconsider this?

[tbu-]

I added a function to the trait that is unimplementable without panic! in code outside this module, so that this only lets the std lib decide later to generalize the key of VecMaps. I'd like to add similar things to Bitv and BitvSet, after discussion of this.

[Gankra]

I believe we have a plan to make default args involved in inference, which would mean the hack to avoid this wouldn't be necessary?

[tbu-]

Depends. One thing to consider would be whether the type parameter for the key should be the first or the second.

[Diggsey]

It probably shouldn't be using "uint", but "usize"

[nikomatsakis]

@gankro @tbu- perhaps we should discuss this on IRC?

[nikomatsakis]

clearly this should be usize

[tbu-]

The conclusion of the discussion on IRC is that we might want to add this in a different way, later.