Foo contains the exact same bits that the vtable of
Bar has (plus more) if
Foo: Bar (and no other trait bounds). In llvm we end up with two vtables which each require their own static memory slot. We know for a fact though that duplicating or deduplicating vtables is perfectly legal (since duplicating happens across crates, see docs and discussion on the
ptr::eq method). Before lowering vtables to llvm, we could have a table of existing vtables and look through it to find any vtables that start with the exact memory of the entire vtable we currently want to lower. If we find that, we just yield the already lowered (bigger or equal) vtable. We can even go further at some point and check whether vtables for different types can be deduplicated (which should be possible if all methods have the exact same body), but the low hanging fruit of deduplicating vtables for a single type but multiple traits is something I think we could fix and that
-Os could benefit from
How does that interact with rfc 2580? If I
&Bar and get back a
VTable<Foo> I guess that would be fine now.
But if we extended the API's in the future to allow introspecting the available methods, then it would be very confusing/potentially a bug.
You'd still get a
Vtable<Bar> in the type system. It's just a deduplication of the backing memory of the vtables. So the pointers will alias, not sure if that is a problem
I guess since
Vtable::Metadata doesn't implement
PartialEq, there's no safe way of discovering that
Seems reasonable then
in RFC 2580 the
Metadata needs to impl
Ord which implies impl
but even with the same type
Foo, the vtable constructed from crate A and that from crate B could be in different locations
basically, if you think this feature is going to affect code relying on vtable equality, perhaps those code are already buggy themselves.