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

Negative interaction between &self, auto-ref, and @T implementations #3585

Closed
nikomatsakis opened this issue Sep 25, 2012 · 0 comments
Closed
Labels
A-typesystem Area: The type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone

Comments

@nikomatsakis
Copy link
Contributor

@erickt stumbled across a negative interaction between the current auto-ref/auto-deref rules, explicit self, and implementations for @T.

If you write code like this:

trait Foo {
    fn foo(&self) -> ~str;
}

impl<T: Foo> @T: Foo {
    fn foo(&self) -> ~str {
        fmt!("@%s", (**self).foo())
    }
}

impl uint: Foo {
    fn foo(&self) -> ~str {
        fmt!("%u", *self)
    }
}

fn main() {
    let x = @3u;
    assert x.foo() == ~"@3";
}

You get an assertion failure. What happens is that auto-ref derefs the @uint to uint and then auto-refs that to &uint. This is because the current rule is "auto-deref until you can't, then auto-ref". It would be easy enough to make it try auto-refing at each stage. Probably it should, this seems like an important use case. This is a fairly small change to middle/typeck/check/method.rs.

erickt added a commit that referenced this issue Sep 26, 2012
Unfortunately this trips over issue (#3585), where auto-ref isn't
playing nicely with @t implementations. Most serializers don't
care, but prettyprint2 won't properly display "@" until #3585 is
fixed.
erickt added a commit that referenced this issue Sep 26, 2012
Unfortunately this trips over issue (#3585), where auto-ref isn't
playing nicely with @t implementations. Most serializers don't
care, but prettyprint2 won't properly display "@" until #3585 is
fixed.
RalfJung pushed a commit to RalfJung/rust that referenced this issue May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

1 participant