Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make object types not implement their associated trait #5087

Closed
nikomatsakis opened this issue Feb 22, 2013 · 1 comment
Closed

Make object types not implement their associated trait #5087

nikomatsakis opened this issue Feb 22, 2013 · 1 comment
Assignees
Labels
A-trait-system Area: Trait system

Comments

@nikomatsakis
Copy link
Contributor

Currently we have some rather complex rules for when an object type @T (or &T etc) for a trait T implements the trait T. I think we should just say that @T does not implement T.

We can instead add a deriving mode #[deriving_self(managed|borrowed|owned)] to derive an implementation of T for @T, &T, or ~T.

Problems that this avoids

There are a number of unsoundness issues that can result from object types implementing their associated trait. Consider the following examples:

fn foo<T: Eq>(x: &T, y: &T) { ... x.eq(y) ... }
foo::<@Eq>(1 as @Eq, @"hi" as @Eq) // now we are comparing 1.eq("hi")!

trait AtFoo { fn foo(@self, ...) { ... } }
fn bar<T: AtFoo>(x: @T) { x.foo(); }
bar::<~AtFoo>(@(x as ~AtFoo)) // now we are calling `bar()` with a `~Foo` receiver!

trait MakeMe { fn foo() -> Self { ... } }
fn bar<T: MakeMe>(x: T) { ... let y = MakeMe::foo(); ... }
bar::<@MakeMe>(1 as @MakeMe); // now x has type @MakeMe but y has type int

We can come up with rules that prevent these examples, but those rules ultimately get quite complex. Simply saying that @T does not implement T avoids all these problems. Then we can add a deriving rule. All of the scenarios above would result in a type check violation when you tried to actually write out that impl.

@nikomatsakis
Copy link
Contributor Author

Removed RFC tag as this was agreed to in today's meeting.

bors added a commit that referenced this issue Mar 6, 2013
…l-self, r=pcwalton

Two changes:

- The first fixes an inconsistency in coherence whereby extension methods were added to the inherent methods table, but only in cross-crate scenarios.  This causes some minor fallout in tests and so forth.  In one case (comm) I added inherent and trait methods so as to avoid the need to import traits like `GenericPort` just to use a port.

- The second makes objects not implement the associated trait, as discussed in #5087.

r? @pcwalton
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
improve `empty_enum` documentation

closes rust-lang#4905
changelog: improve `empty_enum` help message and documentation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system
Projects
None yet
Development

No branches or pull requests

1 participant