{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicyhnujxf5hxbtcouoe7ersfli6lawp6ie3fhcf34hpwsc7o77vba",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjfske2j2qg2"
  },
  "path": "/t/pre-rfc-btf-relocations/24161#post_14",
  "publishedAt": "2026-04-13T18:55:00.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Sized hierarchy"
  ],
  "textContent": "vad:\n\n> RalfJung:\n>\n>> FWIW this will be very non-trivial because Rust has generics. Today one can write a generic function that takes an arbitrary `T` (implicitly: `T: Sized`) and then obtain its size as a compile-time constant. This is not something we can break. That's why people are saying that the Sized hierarchy work is a prerequisite for supporting this kind of a type.\n>\n> I'm fine with making support for BTF relocations depend on the `Sized` hierarchy work if there is strong opposition to introducing `#[repr(btf)]` types that don't work with generics.\n\nIt may not be as hard of a blocker as that makes it sound.\n\nFirst, you may be able to start with an unstable implementation even if the `Sized` hierarchy is a blocker for stabilization. This is the case for scalable vectors, which already have a prototype implementation in the compiler despite the `Sized` hierarchy not yet having one.\n\nSecond, you may be able to come up with a subset of the feature that doesn't depend on the `Sized` hierarchy at all. This should be easier for BTF types than for scalable vector types. The prototype of scalable vector types is pretty hacky: the compiler treats these types as `Sized` (despite the lack of a compile-time constant size), with the intent to downgrade to runtime-sized once that becomes a thing. This is because scalable vectors need to be passed by value and treated as `Copy`, which isn't supported for `!Sized` types. For BTF types, though, passing by value is not that essential, so you could probably start by making them `!Sized`, with the intent to _upgrade_ to runtime-sized once that becomes a thing. This would be backwards-compatible and wouldn't break any existing generic code, so maybe it would even be stabilizable? (but I'm only speculating on that.)\n\nThe innovation would be having a type be `!Sized` but still allowing struct field access on it. You still need to work out the proper operational semantics for that, but that seems reasonably orthogonal to the `Sized` hierarchy.\n\nUnfortunately, this would probably only work for structs. For arrays, Rust array types (`[T]`) require the element to be `Sized`, so it probably makes sense to wait for the `Sized` hierarchy before trying to relax that.",
  "title": "[Pre-RFC] BTF relocations"
}