Allow refinement of existing method types in subtraits

[thestinger]

You're currently allowed to implement stronger guarantees in the impl of a trait, like adding regions to borrowed pointers. It would be very useful to be able to do the same thing with users of the trait, as in requiring a stricter version of the trait. At the moment you can't write generic code that requires the stronger guarantee provided by a subset of the implementations.

A good example of this is the each method for iterators, since some containers or generators don't actually store the values they're returning references to. For example, SmallIntMap doesn't actually store the keys.

[nikomatsakis]

To be a bit more formal, if the trait A defines a method M with type T, then a trait B that extends A could also define a method M with a type T2 so long as T2 <: T. As @thestinger noted, we already say that an impl for A can define a method M with a type T2 where T2 <: T (for similar reasons).

This also permits things like Java's covariant return types which can be very useful in some situations. This will be increasingly important when/if we add new kinds of subtypings, such as enum refinements, subtyping between structures, etc.

[catamorphism]

Nominating for milestone 3, feature-complete

[graydon]

accepted for far future milestone

[nikomatsakis]

I've come to realize that this is more complicated than I appreciated at first. the problem is that the idea of refining traits is somewhat incompatible with the notion we inherited from Haskelll where impls of a supertrait are independent from the impl of a subtrait. This notion is good though because it lets you extend traits in a separate crate and then implement the extension.

We can easily combine both the object-oriented view and the Haskell-y view by allowing an impl to implement both a super and a subtrait at the same time, but this is definitely far future sort of thing.

[nikomatsakis]

Another approach is just to say that if trait Sub refines trait Base, then if type T implements trait Sub, we can check the impl of Base for T and check it meets the requirements of Sub. Possibly we could require that the impl of Base for T be in the same crate as the impl of Sub, though that's not strictly needed.

[nikomatsakis]

A related issue pointed out by @wycats -- it'd be nice to have a way to have default method implementations that are more scoped. So, for example, I might want to define a Vehicle base trait with a method drive(), and then Car with a default drive that all cars can use, but not trucks.

[steveklabnik]

Triage: nothing to add

[steveklabnik]

This will shake out as part of the specialization/"inheritance" RFCs, where similar things are being discussed. Closing in favor of them.