Upcasting trait object to supertrait

[comex]

If there's a trait Sub: Super, and I have a &Sub, I should be able to cast it to &Super.

This is essentially a special case of #1277, which proposes allowing arbitrary multi-trait trait objects, e.g. &(A + B + C + D), which can be upcasted to any subset of the list of traits, e.g. &(A + C). The problem is that achieving that seems to require either (a) generating an exponential number of vtables, one for each subset, (b) putting several different vtables in a single trait object reference ("obese pointers"), which has a lot of downsides, or (c) using some indirect approach that would likely compromise the efficiency of method lookup. None of these alternatives look good. That doesn't mean we should give up, since both multi-trait trait objects and arbitrary upcasting are highly desirable in order to improve consistency with the generics system, and generally to make things "just work". But it seems like there needs to be some significant experimentation and exploration before the feature can even be spec'ed out at the RFC level.

On the other hand, simply allowing upcasting to supertraits doesn't face the same obstacles. Even if rustc always generated a separate vtable for every trait in the hierarchy, the bloat would be linear in the number of traits, not exponential - much less of an issue. And it would be a straightforward optimization to have a given trait's vtable layout be based on one of its supertraits' (perhaps the first mentioned), with additional methods appended at the end, so that it can be upcasted to that supertrait just by bitcasting the vtable pointer. Thus, trait hierarchies which are long but linear wouldn't result in any additional overhead.

[Centril]

Small note: I think this will be read by a wider audience and discussed better at the internals forum; The issue tracker here is mostly not read by the lang (or other) team.

[Ixrec]

afaik it already has an internals thread: https://internals.rust-lang.org/t/wheres-the-catch-with-box-read-write/6617

[Centril]

Yes, closing in favor of that.