Skip to content

Implement new orphan rule that requires that impls of remote traits meet... #20594

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

Merged
merged 1 commit into from
Jan 6, 2015

Conversation

nikomatsakis
Copy link
Contributor

Implement new orphan rule that requires that impls of remote traits meet the following two criteria:

  • the self type includes some local type
  • type parameters in the self type must be constrained by a local type

r? @aturon
cc @arielb1
cc #19470

@nikomatsakis nikomatsakis force-pushed the orphan-ordered branch 2 times, most recently from 04d50dc to f64a798 Compare January 5, 2015 22:15
…eet the following two criteria:

- the self type includes some local type; and,
- type parameters in the self type must be constrained by a local type.

A type parameter is called *constrained* if it appears in some type-parameter of a local type.

Here are some examples that are accepted. In all of these examples, I
assume that `Foo` is a trait defined in another crate. If `Foo` were
defined in the local crate, then all the examples would be legal.

- `impl Foo for LocalType`
- `impl<T> Foo<T> for LocalType` -- T does not appear in Self, so it is OK
- `impl<T> Foo<T> for LocalType<T>` -- T here is constrained by LocalType
- `impl<T> Foo<T> for (LocalType<T>, T)` -- T here is constrained by LocalType

Here are some illegal examples (again, these examples assume that
`Foo` is not local to the current crate):

- `impl Foo for int` -- the Self type is not local
- `impl<T> Foo for T` -- T appears in Self unconstrained by a local type
- `impl<T> Foo for (LocalType, T)` -- T appears in Self unconstrained by a local type

This is a [breaking-change]. For the time being, you can opt out of
the new rules by placing `#[old_orphan_check]` on the trait (and
enabling the feature gate where the trait is defined). Longer term,
you should restructure your traits to avoid the problem. Usually this
means changing the order of parameters so that the "central" type
parameter is in the `Self` position.

As an example of that refactoring, consider the `BorrowFrom` trait:

```rust
pub trait BorrowFrom<Sized? Owned> for Sized? {
    fn borrow_from(owned: &Owned) -> &Self;
}
```

As defined, this trait is commonly implemented for custom pointer
types, such as `Arc`. Those impls follow the pattern:

```rust
impl<T> BorrowFrom<Arc<T>> for T {...}
```

Unfortunately, this impl is illegal because the self type `T` is not
local to the current crate. Therefore, we are going to change the order of the parameters,
so that `BorrowFrom` becomes `Borrow`:

```rust
pub trait Borrow<Sized? Borrowed> for Sized? {
    fn borrow_from(owned: &Self) -> &Borrowed;
}
```

Now the `Arc` impl is written:

```rust
impl<T> Borrow<T> for Arc<T> { ... }
```

This impl is legal because the self type (`Arc<T>`) is local.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jan 6, 2015
Conflicts:
	src/libsyntax/feature_gate.rs
@bors bors merged commit 6e68fd0 into rust-lang:master Jan 6, 2015
@nikomatsakis nikomatsakis deleted the orphan-ordered branch March 30, 2016 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants