{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidrsnwpt6umv7cohiuzb2itp33ksq2q274xdlbpfj4ue4fzsu6hlu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mju6ywq7fsc2"
  },
  "path": "/t/pre-rfc-t-trait-dyn-trait/21911#post_11",
  "publishedAt": "2026-04-19T13:37:08.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "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:\n\n\n    fn kita(a: &dyn PartialEq<u32>, b: &dyn PartialEq<u32>) {\n        // Compiler doesn't know the 2 types are the same\n    }\n\n\nthere 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)`.\n\nThis could potentially be given as (with a \"fake\" type parameter):\n\n\n    fn kita<T: PartialEq<u32>>(a: &dyn T, b: &dyn T) {\n        // Compiler knows the 2 types are the same and can share the vtable\n    }\n\n\nor\n\n\n    fn kita<dyn T: PartialEq<u32>>(a: &T, b: &T) {\n        // Compiler knows the 2 types are the same and can share the vtable\n    }\n\n\nIn my opinion the biggest gain is correctness and expressivity, although a point can also me made about memory or performance.\n\n_**The important caveat here is that in the case of a shared`vtable` 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",
  "title": "Pre-RFC: &[T: Trait] -> &dyn [Trait]"
}