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
-
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
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
-
-
yeah now I know that `impl Trait for OtherTrait` really means `impl Trait for dyn OtherTrait` and `dyn OtherTrait` is a specific type, I can treat that as an abstraction, but I still find the underlying memory stuff useful
-
not least because so much of rust's type system is concerned with memory management, even though it's in a more abstract sense than C or asm
End of conversation
New conversation -
-
-
not really, arbitrary pointer types wouldn't be able to wrap this the same way then (right now Arc<T> casts to Arc<dyn Trait>) Unless you do double indirection, in which case dyn Trait is basically just Box<dyn Trait> everywhere, including in borrows (ew)
-
Right, that's what I mean. We could have done double indirection. We didn't for perf reasons. It doesn't change the semantics meaningfully though (I'm assuming most folks aren't doing things that care about the size of a pointer)
- 1 more reply
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.