{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibbdw7jmqb6thplgrjp24qeocwigo7dbx5o4cfk46ciaktmi27cca",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mliaohac6xy2"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289#post_4",
  "publishedAt": "2026-05-10T05:58:42.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "RFC 3301",
    "drawbacks"
  ],
  "textContent": "> By \"cannot return torn values\" you mean that the cases where values would be torn, it'll just be UB instead, right?\n\nExactly. Writes are still done through `UnsafeCell`, so they must be serialized. A valid read, i.e. not racing with writes, means a torn value cannot be observed.\n\n> Though I'm not sure exactly on your subsequent point: what is \"the `Drop` issue of RFC 3301\" that you're avoiding? _(That's a long RFC and even longer discussion, so I have no idea what exactly you're referring to.)_\n\nRFC 3301 `AtomicPerByte` contains a `MaybeUninit`, so it cannot drop its content. So, even if you use it with a content which is always defined, for example in a `SeqLock`, you sill have to drop its content manually. This is mentioned as error-prone in the RFC drawbacks, and the RFC even mention to limit the content of `AtomicPerByte` to be `Copy`.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}