Found some text traits/crates on this page:
https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces
I don't 100% know that it is current, but it is listed on
'https://github.com/mozilla/rust/wiki/Proposals' under 'historical,
implemented'.
"
Under instance coherence, only one implementation of a trait per type
is allowed. Haskell enforces this property at link time, because
conflicting implementations might only be discovered when separate
compilation units are linked. However, in Rust we're interested in
forbidding conflicting implementations sooner.
Consider a program consisting of four interlinked crates C1, C2, C3, and C4,
where C1 defines the trait C1Trait and C2 defines the type C2Type. Under
instance coherence, crate C3 would
not be allowed to directly define an impl of C2Type for C1Trait,
because this leaves us open to the possibility of crate C4 doing the
same thing, resulting in conflicting implementations. However, this
is not a problem for expressivity, because it is always possible for C3 to
create a new nominal alias for C2Type and then define an
impl for that type. Alternatively, both the trait and the impl
could be defined in C1."
So it does appear to be link safe.
Alex
>________________________________
> From: Jonathan S. Shapiro <[email protected]>
>To: Discussions about the BitC language <[email protected]>
>Sent: Wednesday, July 17, 2013 5:08 PM
>Subject: Re: [bitc-dev] Rust was Re: Improvements on library allocation
>
>
>
>On Tue, Jul 16, 2013 at 9:55 PM, Bennie Kloosteman <[email protected]> wrote:
>
>Why cant i have a large standard lib ...with traits and use a lot of c style
>modules in my code "modules" ? Together they form a large app...
>
>
>Because trait implementations either (a) do not respect crate boundaries
>[according to the language reference] or (b) mean that generic functions whose
>instantiations make use of traits cannot access the trait implementations for
>types defined in some other crate.
>
>
>In the first case, there is a coherence problem, an induced whole-crate
>compilation requirement, and a failure of link safety. In the second case,
>traits are effectively unable to cross crate boundaries, which is what the
>manual seems to imply.
>
>
>The impact of the second alternative would be pretty bad. It means that a sort
>implementation in one crate that relies on an implementation of an Ord trait
>cannot make use of an Ord implementation supplied in another crate. That is:
>unless traits are first class types, which is a potentially interesting way to
>resolve this puzzle.
>
>
>The main problem that concerns me about trait implementations and type class
>implementations is the link safety problem. If a reasonable bound can be set
>on the link safety problem, then I think things can be made to work.
>
>
>Oh. The absence of a single implementation at any given type also gives rise
>to some pretty bad dictionary merge problems...
>
>
>"App architecture is unquestionably important. No argument. Nonetheless,
>mistakes in the language design - in this case the absence of lexical scoping
>for impls (aka type class instances) - can destroy any hope of success for the
>best imaginable architecture."
>>
>>
>>I dont think it stopped Haskell ...
>
>
>Umm. Bennie? Name one large system that has been implemented in Haskell.
>Haskell hasn't been stopped because it hasn't attempted the challenge.
>
>
>
>
>Jonathan
>_______________________________________________
>bitc-dev mailing list
>[email protected]
>http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
