DST: cannot provide inherent impl for traits

[aturon]

This code:

trait Foo {}

impl Foo {
    fn foo(&self) {}
}

generates this error:

impl-dst.rs:3:1: 5:2 error: duplicate definition of type or module `Foo`
impl-dst.rs:3 impl Foo {
impl-dst.rs:4     fn foo(&self) {}
impl-dst.rs:5 }
impl-dst.rs:1:1: 1:13 note: first definition of type or module `Foo` here
impl-dst.rs:1 trait Foo {}
              ^~~~~~~~~~~~

I couldn't find any existing issue on this, but this is expected to work, right?

[aturon]

cc @nick29581

[bluss]

Was this in an RFC?

[huonw]

@bluss DST was pre-RFC (the design anyway), so no, it was not.

[nrc]

It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc @nikomatsakis to check he agrees.

[aturon]

@nick29581 As I understand it, an impl for a trait would be quite different than providing default methods:

• Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods.
• The methods cannot be overridden in an impl.
• The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence.

I think the closer correspondence is to creating an extension trait with a blanket impl -- and given that inherent impls are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense.

My guess is that this was an intended, but implicit part of the DST proposal, but @nikomatsakis can speak more directly to that.

[nrc]

These subtle differences make me want it less. But the blanket impl-like use case seems legitimate.

I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point

[nikomatsakis]

I've always assumed this would work but I'm curious @aturon was there a specific point in the libraries that required it?

[aturon]

@nikomatsakis IIRC this came out of playing around with the Any method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.

[nrc]

I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on #18121 landing before doing this

[reem]

I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases.

@aturon Note that since std::any is currently marked stable adding this later would mean deprecations etc.