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

It is an error to incompatibly override an equivalence constraint. #6

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions text/0000-trait-alias.md
Original file line number Diff line number Diff line change
Expand Up @@ -150,6 +150,22 @@ more predicates, just like any other `where` clause.
You cannot directly `impl` a trait alias, but you can have them as *bounds*, *trait objects* and
*impl Trait*.

----

It is an error to attempt to override a previously specified
equivalence constraint with a non-equivalent type. For example:

```rust
trait SharableIterator = Iterator + Sync;
trait IntIterator = Iterator<Item=i32>;

fn quux1<T: SharableIterator<Item=f64>>(...) { ... } // ok
fn quux2<T: IntIterator<Item=i32>>(...) { ... } // ok (perhaps subject to lint warning)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this shoudn’t be authorized?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy either way.

Originally I was going to list it as disallowed, as you suggest.

But then I worried that might not be consistent with other design choices. E.g. one can add where clauses that are already implied by pre-existing constraints, right? So should it be an error to add a redundant equivalence constraint?

Maybe best (or at least easiest in terms of getting the RFC merged) to take out the fn quux2 example, and then make a new Unresolved Question for this case?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I think you’re right about the consistency. Others construct follow such a pattern. I’ll merge it then.

fn quux3<T: IntIterator<Item=f64>>(...) { ... } // ERROR: `Item` already constrained

trait FloIterator = IntIterator<Item=f64>; // ERROR: `Item` already constrained
```

---

When using a trait alias as a trait object, it is subject to object safety restrictions *after*
Expand Down