{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie3flrx7wwtcw5sevysjmcgbbkgorthxrccx4dfmxbmxjxh7x4ury",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgcvduck4pi2"
  },
  "path": "/t/interior-mutability-and-safety-of-ownership-transfer-in-rust/24055#post_2",
  "publishedAt": "2026-03-05T12:40:49.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "`Freeze`"
  ],
  "textContent": "So I just stumbled over the unstable `Freeze` trait. This seems like a perfect trait bound for the `K` and `V` types in order to prevent data races for types with interior mutability (e.g. `HashMap<Arc<str>, AtomicUsize>`) during buffer migration.\n\nPersonally, I think a language level `&const T` would be even better - or at least more flexible - but for now this seems suitable to me.\n\nThat said, the question remains if this idea of mine is sound within the constraints of Rust's ownership model in general. For example, is it safe to have an old Buffer A containing a \"non-owning\" `Vec<T>` accessed via shared reference by some threads while simultaneously a new Buffer B containing a bit-wise copy of the same `Vec<T>` and logical ownership of it is accessed via shared references by other threads.",
  "title": "Interior mutability and safety of ownership transfer in Rust"
}