{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiht6ccvjk4ll2towoaeleyftktb72asbqqomwunbb2d5hcdxqakb4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjk2n23yhzy2"
  },
  "path": "/t/pre-rfc-btf-relocations/24161#post_16",
  "publishedAt": "2026-04-15T12:54:47.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "ais523:\n\n> I think the opsem here is to have what is in effect a global variable (`static` used like a `const`) that stores the offset of a particular field, for field projection to be implemented by pointer arithmetic using the offset from the global variable, and for other field accesses to be implemented in terms of field projection. One advantage of doing things this way is that it should desugar pretty easily into MIR or even surface Rust, so the opsem aspects would be confined to stating/implementing the lowering rather than needing to add new opsem rules.\n\nYeah that is plausible -- it's basically a struct layout that's defined at program start time rather than at compile time (and might be different for different program executions).\n\nBut of course that is a huge departure from everything in Rust so far assuming that field offsets (to sized fields) are constant, so there's still a good chance for interesting surprises when pushing such a change through the compiler. For instance, this would be the first time that a field projection would have to be disallowed in `const fn`.",
  "title": "[Pre-RFC] BTF relocations"
}