The key parameter of Index should be made an associated type

[sfackler]

The orphan check rules currently prevent implementations of Index with the key type generic over BorrowFrom.

src/ordered_map.rs:64:1: 70:2 error: type parameter `T` must also appear as a type parameter of some type defined within this crate
src/ordered_map.rs:64 impl<K, V, Sized? T> Index<T> for OrderedMap<K, V> where T: Eq + PhfHash + BorrowFrom<K> {
src/ordered_map.rs:65     type Output = V;
src/ordered_map.rs:66 
src/ordered_map.rs:67     fn index(&self, k: &T) -> &V {
src/ordered_map.rs:68         self.get(k).expect("invalid key")
src/ordered_map.rs:69     }
                      ...
src/ordered_map.rs:64:1: 70:2 note: for a limited time, you can add `#![feature(old_orphan_check)]` to your crate to disable this rule
src/ordered_map.rs:64 impl<K, V, Sized? T> Index<T> for OrderedMap<K, V> where T: Eq + PhfHash + BorrowFrom<K> {
src/ordered_map.rs:65     type Output = V;
src/ordered_map.rs:66 
src/ordered_map.rs:67     fn index(&self, k: &T) -> &V {
src/ordered_map.rs:68         self.get(k).expect("invalid key")
src/ordered_map.rs:69     }
                      ...

cc @nikomatsakis @japaric

[japaric]

I don't think Key should become an associated type, that would limit the usefulness of the indexing sugar. And in particular, it makes impossible to implement both indexing and slicing on slices (we need Index<uint> and Index<Range<uint>>).

[aturon]

@sfackler this is cropping up in a few other places and we are thinking of further revising the coherence rules to make this pattern OK.

I'm not quite sure what you're suggesting here, though? What do you mean by the "key parameter" for Index? We can't make the index itself an associated type or we'd lose overloading.

[japaric]

(Can't comment on the orphan rules, not familiar with the new rules)

[aturon]

cc the discussion here and onward.

[nikomatsakis]

Closing because this is not desirable and the orphan rules have been fixed.