-
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
Impl search fails in case of generalized trait inheritance #10950
Comments
file under #5527 -- it is a good point. |
The error for this sample is now
|
Triage: same error, but with extra message:
Also, you need the old impl check here:
|
Even without the old impl check, this example no longer makes sense, because it uses the old unary tuple dereferencing syntax. Today, the compiler is correct that type trait Foo {
fn foo(&self, x: &Self);
}
trait Bar {
type A: Foo;
fn bar(&self) -> Self::A;
}
struct Wrap<T>(T);
impl<B: Bar> Wrap<B> {
fn test(&self, x: &B::A) {
self.0.bar().foo(x);
}
}
fn main() {} compiles successfully. I think this issue can be closed. |
Well this still fails, and seems like morally still at least somewhat similar. trait Foo { fn foo(&self, x: &Self); }
trait Bar<A: Foo> { fn bar(&self) -> A; }
struct Wrap<T>(T);
fn test<A, B: Bar<A>>(wrap: Wrap<B>, x: &A) {
wrap.0.bar().foo(x);
}
fn main() {} |
This is intentional - non-supertrait bounds are not elaborated. |
Closing as a duplicate of #20671, which has a better explanation. |
…st_doc_block, r=xFrednet [`needless_doctest_main`]: ignore `main()` in `no_test` code fences close rust-lang#10491 *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: [`needless_doctest_main`]: ignore `main()` in `no_test` code fence
The following program fails to compile:
With the following error:
Given that
B: Bar<A>
, we knowA: Foo
because of the definition of the trait Bar. This can be seen as a generalized case of trait inheritance (trait B inheriting from A lets us know that ifX:B
, thenX:A
, becauseX:B
requiresX:A
; similarly,B:Bar<A>
requiresA:Foo
, so we knowA:Foo
). Indeed, in Haskell there is no distinction between the two forms of inheritance:The order of arguments to Bar could be switched and the program above would still be valid.
The text was updated successfully, but these errors were encountered: