I suppose that could work, I did not think of it. Wouldn't that require the
trait methods to be named differently?


On Mon, Apr 7, 2014 at 10:29 AM, Niko Matsakis <notifications@github.com>wrote:

> In active/0000-less-trait-imports.md:
>
> > +one wants to call a trait-provided method on a type. This can become
> > +burdensome for crates which have many abstractions. Second, it causes a
> > +backwards compatibility hazard when factoring out behavior into a common
> > +trait. In order to do the refactor, all dependent crates must now start
> > +importing this new trait.
> > +
> > +This restriction causes pain for all non-extension-implementation uses of
> > +traits. An extension implementation is when a crate defines its own trait,
> > +but implements that trait for types in other crates.  The less restrictive
> > +system proposed here is to instead use methods from an extension
> > +implementation only if that trait is in scope.
> > +
> > +A more concrete example arises in `libterm`. Ideally `AnsiTerminal` would be a
> > +trait with `Win32Terminal` and `TerminfoTerminal` implementing it. Doing so,
> > +however, affects every use of the crate. Were `libterm` marked stable,
> > +introducing such an abstraction would be impossible. I worry that this will be
>
> This is not strictly true. You can define inherent methods that delegate
> to identical trait methods (and I've done so in order to introduce traits
> in a backwards compatible way before).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/rust-lang/rfcs/pull/37/files#r11345562>
> .
>



-- 
http://octayn.net/