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

Can't cast self to trait object in default methods #7320

Closed
Blei opened this issue Jun 23, 2013 · 15 comments
Closed

Can't cast self to trait object in default methods #7320

Blei opened this issue Jun 23, 2013 · 15 comments
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@Blei
Copy link
Contributor

Blei commented Jun 23, 2013

The following code doesn't work (even though I suspect it's correct):

trait Foo {
    fn foo(@self) { bar(self); }
}

fn bar(_b: @Foo) { }

The following error is returned:

<anon>:2:24: 2:29 error: mismatched types: expected `@Foo` but found `@Self` (expected trait Foo but found @-ptr)
<anon>:2     fn foo(@self) { bar(self); }
                                 ^~~~~
error: aborting due to previous error
@Blei
Copy link
Contributor Author

Blei commented Jun 26, 2013

Related to (or duplicate of?) #7183

@pnkfelix
Copy link
Member

@Blei might be related, but I would not call it a duplicate; the type &S in fn<S:Trait>(s:&S) does not use dynamic dispatch (i.e. does not carry a virtual-method table) while @Trait in fn(x:@Trait) does.

(as in, the use-cases for the two are so different, I'd want to ensure they are addressed, independently if necessary. Though maybe we will be lucky and they will end up having the same root cause.)

@pnkfelix
Copy link
Member

Regardless of whether this is a dupe of 7183, it is definitely part of #2794.

@msullivan
Copy link
Contributor

The code I think is not correct. It doesn't actually do a cast.

@msullivan
Copy link
Contributor

I feel like the code should be

trait Foo {
    fn foo(@self) { bar(self as @Foo); }
}

fn bar(_b: @Foo) { }

This fails with

../rust-things/default-self-object.rs:2:24: 2:36 error: cannot pack type `@Self`, which does not fulfill `'static`, as a trait bounded by 'static
../rust-things/default-self-object.rs:2     fn foo(@self) { bar(self as @Foo); }

Hm.

@Blei
Copy link
Contributor Author

Blei commented Jun 28, 2013

Yes, I tried multiple variants, both with and without cast. I meant to paste the one with a cast, but alas.

@nikomatsakis
Copy link
Contributor

Sully's error is legit, in the sense that the type system is operating as expected. The type Self may contain borrowed pointers, and the type @Foo is short for @Foo:'static, which says that the value does NOT contain borrowed pointers. The correct way to implement the example (which I think does not work yet) would be:

trait Foo : 'static { ... }

which would say that the trait Foo cannot be implemented except by types that do not contain borrowed pointers.

If we added the rule that @ boxes cannot contain managed pointers, as we have discussed, it is plausible that we could then extend the type system to know that Self has the bound 'static in an @self method (or any method that contains an @Self parameter). I described such a scheme in this blog post about the Sized kind.

@pnkfelix
Copy link
Member

@nikomatsakis FYI, when I attempted this morning to replicate the issues I was having with syntax::visit @Visitor refactoring, I ran into this problem (I think). Or at least, I could not pass @self to helper methods from the default method implementations in visit.rs. (There are ways to work-around this, such as not using default methods.)

@flaper87
Copy link
Contributor

The following example works:

trait Foo {
    fn foo(&self) { bar(self); }
}

fn bar(_b: &Foo) { }

fn main() {}

Since @ is being deprecated in favor of Gc and Rc and the above example works, I think we can close this issue. @nikomatsakis @pnkfelix thoughts?

@huonw
Copy link
Member

huonw commented Jan 29, 2014

Does ~self and ~Foo work?

@flaper87
Copy link
Contributor

trait Foo: Send {
    fn foo(~self) { bar(self as ~Foo); }
}

fn bar(_b: ~Foo) { }

fn main() {}

Yes, it works!

@flaper87
Copy link
Contributor

Closing based on the above comments

@flaper87
Copy link
Contributor

Reopening since the above example requires Send to be explicitly specified

@flaper87 flaper87 reopened this Jan 29, 2014
@flaper87
Copy link
Contributor

To be more specific. The same thing that happens here can be reproduced w/ ~Foo:

trait Foo {
    fn foo(~self) { bar(self as ~Foo); }
}

fn bar(_b: ~Foo) { }

fn main() {}
test.rs:2:25: 2:32 error: cannot pack type `~Self`, which does not fulfill `Send`, as a trait bounded by Send
test.rs:2     fn foo(~self) { bar(self as ~Foo); }
                                  ^~~~~~~
error: aborting due to previous error

@huonw
Copy link
Member

huonw commented Apr 26, 2014

We no longer have the default bounds on ~ trait objects, but, in any case, the original code has worked for a while using ~Foo: to explicitly override the Send bound, i.e. this issue had been fixed. (The old ~Foo/new ~Foo:Send cast fails because Self isn't known to be Send in that context; if sendability is necessary, writing trait Foo: Send { ... } works).

Flagging as needstest.

bors added a commit that referenced this issue Apr 28, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 30, 2021
…g#7320

When inverting an expression, the output is now like ```foo != 0``` instead of ```!(foo == 0)```, the comparison operator is now replaced.
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 30, 2021
update: ```Sugg::not()``` replacing the comparison operator. rust-lang#7320

fixes rust-lang#7320

changelog: ```needless_bool```: Changed to make a smart suggestion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants