Pre-RFC: &[T: Trait] -> &dyn [Trait]

IMO we should think broader than just slices. Slices are just a special case of a wider requirement of sharing a vtable/metadata across types in a fn signature. Take this example:

fn kita(a: &dyn PartialEq<u32>, b: &dyn PartialEq<u32>) {
    // Compiler doesn't know the 2 types are the same
}

there is no way for the author of a function kita to constrain the fn signature to allow only arguments of the same type, although the exact type is unknown. This fn would only allow calls like: kita(&0_u32, &1_u32) but not: kita(&0_u32, &1_i32).

This could potentially be given as (with a "fake" type parameter):

fn kita<T: PartialEq<u32>>(a: &dyn T, b: &dyn T) {
    // Compiler knows the 2 types are the same and can share the vtable
}

or

fn kita<dyn T: PartialEq<u32>>(a: &T, b: &T) {
    // Compiler knows the 2 types are the same and can share the vtable
}

In my opinion the biggest gain is correctness and expressivity, although a point can also me made about memory or performance.

The important caveat here is that in the case of a sharedvtable pointer, it doesn't belong to/is not owned by the type, it belongs to/is owned by the function. This eliminates the 3-wide pointer issue, but may bring problems of its own. I suspect the actual layout of the function type might present some challenges (because it would carry implicit vtable pointers) and how that would interoperate with ABI stability or type equality