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

Error E0399 regression on nightly from beta. #27377

Closed
dylanede opened this issue Jul 29, 2015 · 7 comments
Closed

Error E0399 regression on nightly from beta. #27377

dylanede opened this issue Jul 29, 2015 · 7 comments

Comments

@dylanede
Copy link
Contributor

I have found that with a trait of the form

trait Foo {
    type A = ();
    fn get_a(&self) -> Option<Self::A> { None }
    type B = ();
    fn get_b(&self) -> Option<Self::B> { None }
}

impl Foo for () {
    type A = ();
}

I get the following error message on nightly (as of the time of this post), but not on beta.

<anon>:9:5: 9:17 error: the following trait items need to be reimplemented as `A` was overridden: `get_a`, `B`, `get_b` [E0399]
<anon>:9     type A = ();

I can possibly understand get_a needing to be reimplemented, but B and get_b as well?
I don't get the error message when types do not have defaults, like so:

trait Foo {
    type A;
    fn get_a(&self) -> Option<Self::A> { None }
    type B = ();
    fn get_b(&self) -> Option<Self::B> { None }
}

impl Foo for () {
    type A = ();
}

Note that it no longer errors out saying that the methods need to be reimplemented.

@arielb1
Copy link
Contributor

arielb1 commented Jul 29, 2015

That's completely intentional. In fact, 1.2.0 will soon warn on that condition too (#27364).

@dylanede
Copy link
Contributor Author

@arielb1 Why is that intentional? It makes implementing traits that have a lot of default types and methods annoying, since often it makes having default types and methods useless, since if you override one, you've got to override everything.

@dylanede
Copy link
Contributor Author

Having looked at the relevant part in the RFC, I can't see why that approach was taken. It makes more sense to me for the default function implementations to only be allowed to assume the constraints on the associated types, not their default types.

@aturon
Copy link
Member

aturon commented Jul 29, 2015

@dylanede See #26728 (comment) -- we are planning to feature gate defaulted associated types, and will likely alter the semantics away from the RFC toward a design like the one you suggest.

@steveklabnik
Copy link
Member

Should this issue be closed?

@dylanede
Copy link
Contributor Author

dylanede commented Aug 5, 2015

If it is going to be closed then an issue about the changes to the design from the RFC that @aturon talked about should be opened first.

@steveklabnik
Copy link
Member

I'm going to give this one a close, in favor of #29661 , the one tracking stabilizing associated types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants