On Thu, Sep 5, 2013 at 3:36 PM, Tim Chevalier <[email protected]>wrote:
> The reason is that there is no guarantee that you will never use this > code in a context where another module defines an impl of Bar for u16. > In that scenario, you would have two different impls of Foo for u16, > and no way to disambiguate. In Haskell, this is called the > "overlapping instances" problem; it happens because traits in Rust, > and type classes in Haskell, are open rather than closed (when you > define a trait, you don't have any way of knowing all the impls of it > for a particular type). Strictly speaking, you know about all impls of Bar for all types available to your crate when you compile your crate, and if you own Bar, then you even know that new impls can't be introduced in your dependencies which could break your code. You could even have `impl <T: Bar> Foo for T` and `impl<T: Baz> Foo for T`, as long as you own at least one of Bar or Baz, since it is then possible for the compiler to know that types in other crates which depend on yours can't implement both. Its just a matter of how smart you want the compiler to be, and how much you want to avoid changes up the dependency chain being able to break things down the dependency chain (which isn't entirely avoidable anyways).
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
