It's my understanding that Rust traits suffer fewer coherency issues than Haskell type classes because Rust disallows orphan impls, so that in order to implement a trait, either the trait or the data needed to be defined in the same crate.
On Sun, Jul 14, 2013 at 4:06 PM, Jonathan S. Shapiro <[email protected]>wrote: > OK. So I've looked at Rust, and it appears to me that it has exactly the > problem that killed BitC: instance resolution ambiguity. > > Nicholas does a good job of stating his goals > here<http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/>: > coherence, link safety, overloading, and termination. The problem I am > seeing is that Rust trait implementations are exactly like Haskell type > class instances and suffer the same coherency issues. As with Haskell, Rust > requires that a given Trait has at most one implementation for a type T. > Also like Haskell, impls do not appear to be lexically scoped, with the > consequence that (a) generic trait implementations complemented by > specialized implementations aren't resolvable and (b) the "only one > implementation" rule can only be checked on a "whole Crate" basis. > > Except it appears to me that this isn't possible, because a Trait > requirement can appear at an interface, with the result that two crates > interacting through an interface can have independent implementations of > some trait for the same type. > > Am I failing to understand something here? > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > > -- Alex R
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
