Future-prove collections::VecMap
#21290
Conversation
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 has picked a reviewer for you, use r? to override) |
|
Old PR: #20150 |
|
I added a function to the trait that is unimplementable without |
|
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? |
|
Depends. One thing to consider would be whether the type parameter for the key should be the first or the second. |
|
It probably shouldn't be using "uint", but "usize" |
| /// implemented manually currently. | ||
| pub trait VecMapKey { | ||
| #[doc(hidden)] | ||
| fn to_uint(&self) -> uint; |
There was a problem hiding this comment.
clearly this should be usize
|
The conclusion of the discussion on IRC is that we might want to add this in a different way, later. |
Since
VecMapmight want to have key type parameter at some point, add a keytype parameter now, so that code running today will still run when actual
generalization of the key is added.
The trait
VecMapKeyshould really be private, but this is blocked by the factthat you cannot export a struct, function or trait implementation with one of
the type parameters being bound by a private trait.