Closed
Description
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.
Activity
arielb1 commentedon Jul 29, 2015
That's completely intentional. In fact, 1.2.0 will soon warn on that condition too (#27364).
dylanede commentedon Jul 29, 2015
@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 commentedon Jul 29, 2015
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 commentedon 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 commentedon Aug 4, 2015
Should this issue be closed?
dylanede commentedon 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 commentedon Jul 25, 2016
I'm going to give this one a close, in favor of #29661 , the one tracking stabilizing associated types.