I'm not sure I follow.
Assuming that the trait `T` has no method that uses `Self`, then any `impl`
requiring `T` should happily accept an `&T` / `@T`. Why penalize
non-self-referential traits (like `Writer`), just because some traits (like
`AdderIncr`) are self-referential?
On Sun, Oct 20, 2013 at 1:10 AM, Steven Blenkinsop <steven...@gmail.com>wrote:
> Consider this program:
>
> """
> trait AdderIncr {
> fn add(&self, x: Self) -> Self;
> fn incr(&mut self);
> }
>
> impl AdderIncr for int {
> fn add(&self, x: int) -> int { *self + x }
> fn incr(&mut self) { *self += 1; }
> }
>
> fn incrAdd(x: &mut AdderIncr, y: &mut AdderIncr) {
> x.incr();
> x.add(y);
> }
>
> fn main() {}
> """
>
> It fails to compile:
>
> """
> Documents/test.rs:13:1: 13:10 error: cannot call a method whose type
> contains a self-type through an object
> Documents/test.rs:13 x.add(y);
> ^~~~~~~~~
> """
>
> The Self type is meaningless in object methods, since I have no way to
> ensure that y has the same underlying type as x. Thus, only a subset of the
> methods of a trait are available on the corresponding object, which means
> that objects can't automatically implement their corresponding trait.
>
> That means any impls that implement a trait for all types that implement
> AdderIncr, for example, won't implement that trait for &AdderIncr, since
> &AdderIncr doesn't implement AdderIncr.
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
