Box<TraitObject> should impl TraitObject

[pythonesque]

Also &TraitObject, &mut TraitObject, etc. (I think raw pointers can also reference trait objects). I believe this should be possible now that object safe traits always implement themselves.

cc @nikomatsakis

[nikomatsakis]

This is indeed possible for Box<TraitObject>, but not &TraitObject and so on. At least not for all traits. Consider a trait like:

trait Foo {
    fn method(&mut self);
}

You can't implement that trait for a &Foo -- it can never call method().

[nikomatsakis]

It is not clear to me if we want this for Box<TraitObject>, however. Feels weird to me since Box is not supposed to be a built-in part of the language. I'd think it'd make a good deriving mode (along with & and &mut, perhaps).

[pythonesque]

Yeah, a deriving mode might work.

[tbu-]

A "derive all traits" and a "derive all traits that don't take self by value" and a "derive all traits that only take self by immutable reference" would be nice. This way you don't have to implement the trait for Box, &mut, & and so on, for each trait.

[pythonesque]

On a side note, taken to its extreme it feels like the current system of object safety would eventually lead to the ideal of one method per object-safe trait, and allow arbitrary combinations of them (so you could freely combine whatever combination of object-safe methods you need for your usecase). But at that point object-safe traits are basically just unboxed closures, and casting to a trait object (e.g. for traits A and B, box Foo as Box<A + B>) is just the established way to create a vtable entry from lots of closures sharing the same environment. That may not be a useful way of thinking about it in the context of Rust, though, and it's probably missing something that the current system addresses (genericity over type, maybe?)

[steveklabnik]

Triage: we did this, didn't we?

[nikomatsakis]

On Mon, Jan 04, 2016 at 01:44:05PM -0800, Steve Klabnik wrote:

Triage: we did this, didn't we?

Not quite. We made it so that the type Trait implements the trait
Trait, but not Box<Trait>. That said, I don't think we can or
should do this. It is true that for most traits, Box<Trait> could
implement Trait, but not for traits like

trait Foo: Copy

[nikomatsakis]

I guess if the issue is about a new deriving mode, as we discussed earlier, I could get behind it. But I think the idea of auto-implementing traits feels...perilous and complex. We've largely failed at attempts to achieve this sort of magic.

[apasel422]

The following is another example of a trait that, despite being object-safe, cannot be implemented automatically for Box:

trait Foo {
    fn foo(&self, other: &Self) where Self: Sized;
}

[Mark-Simulacrum]

I get the feeling from reading this that there's not really a clear path forward, and we're not even sure we want this. Either way, it feels like it's something that would need to go through an RFC, so perhaps this should be closed (and if interest still exists, refiled as an RFC issue).

[arielb1]

Sure. Looks like this wants to be an RFC.