oh, because the method calls pass down to the Box contents... okay then I need to better understand what "Box implementing a trait" means, hopefully these new boxed closure features will tell me!
-
-
Replying to @mountain_ghosts @ManishEarth
but also, someone told me you can impl a trait for another trait, rather than for all types that implement said trait, i.e. `impl Trait for Other` rather than `impl<T: Other> Trait for T` and I still don't know what that means or if it's relevant here
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts
That's the same as `impl Trait for dyn Other` (`dyn` is optional, it's an idiom for marking a trait in a type position to mark it as dynamically dispatched). You're implementing the trait only for trait objects of type Other
1 reply 0 retweets 0 likes -
Replying to @ManishEarth
ah so only for &dyn Other, Box<dyn Other>, etc, but not for any T: Other ?
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts
well, to be precise, it implements it for one type: `dyn Other`. &dyn Other, Box<dyn other> get it through deref, but they do not get the trait implemented
2 replies 0 retweets 0 likes -
Replying to @ManishEarth @mountain_ghosts
Box<dyn Other> and &dyn Other are not T: Other, as I mentioned before. They get Other methods through deref. Some traits (eg. Fn*) may choose to blanket implement themselves on these types.
2 replies 0 retweets 0 likes -
Replying to @ManishEarth @mountain_ghosts
dyn Other is a single type. It's a virtually dispatched trait object, with a concrete value of *some* type implementing that trait behind it. It can only exist behind a pointer, because we don't know its size.
2 replies 0 retweets 0 likes -
-
Replying to @mountain_ghosts @ManishEarth
Yes. It points to a vtable with the size information and function pointers to all the trait methods
1 reply 0 retweets 0 likes -
Replying to @sgrif @ManishEarth
but a `dyn Trait` cannot exist as a value on its own? it needs a wrapper type to implement a pointer to the concrete value?
1 reply 0 retweets 1 like
Correct. Something has to actually point to that vtable and size information.
-
-
Replying to @sgrif @ManishEarth
the thing I wasn't getting is that I was thinking about dynamic OO languages, where the class/vtable pointer is part of the value whereas here you have a pair of pointers, one to the value and one to the vtable that's relevant at that call site, it's contextual
1 reply 0 retweets 1 like -
Replying to @mountain_ghosts @ManishEarth
I think that distinction is really just an implementation detail. It could have easily been implemented as `*mut (*const Vtable, Data)` and the semantics would still be the same
2 replies 0 retweets 2 likes - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.