-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Type checker doesn't consider trait duality when reasoning about type parameters for associated types #38917
Comments
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues @nox is going to hit in his Servo script bindings refactor 😉 I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. @nikomatsakis was talking about this in his blog, and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do. |
… TNode. v1 This works around the issue described in rust-lang/rust#38917
… TNode. r=emilio This works around the issue described in rust-lang/rust#38917
This appears to work today; E-needstest. |
I don't think it works necessarily -- if you remove the bound that @bholley highlighted, you still get an error. |
The example that @bholley expected to pass (and I think he is right that it should) is this one: use std::borrow::Borrow;
trait TNode: Sized {
type ConcreteElement: TElement<ConcreteNode = Self>;
}
trait TElement: Sized {
type ConcreteNode: TNode<ConcreteElement = Self>;
}
trait DomTraversal<N: TNode> {
type BorrowElement: Borrow<N::ConcreteElement>;
}
fn recalc_style_at<E, D>()
where E: TElement,
D: DomTraversal<E::ConcreteNode>,
{
}
fn main() {
} |
Current output:
|
Add some tests for associated-type-bounds issues Closes rust-lang#38917 Closes rust-lang#40093 Closes rust-lang#43475 Closes rust-lang#63591 rust-lang#47897 is likely closable too, but it needs an MCVE ~~rust-lang#38917, rust-lang#40093, rust-lang#43475, rust-lang#47897 all are mislabeled and shouldn't have the `F-associated-type-bounds` label~~ ~~rust-lang#71685 is also mislabeled as commented on in that thread~~
See the testcase here: https://is.gd/WZh43I
I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-)
@Manishearth thoughts?
The text was updated successfully, but these errors were encountered: