{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiahp76iicjnxjtvjsrh3vu2fwbs4vsqug3emxrvsxl5f2sddacjpy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlqgfst7kdu2"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289#post_15",
  "publishedAt": "2026-05-13T11:57:10.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "RalfJung:\n\n> josh:\n>\n>> I am not suggesting at any point that we have a \"location for which reads are racy by default\". I do think it makes sense to have \"location that permits explicitly performing racy read operations\", so that writers know that's a possibility to account for, even if not every reader does it.\n>\n> I don't really know what you mean by this.\n\nI'm suggesting that it is potentially useful, from a type-system perspective, to tag things for which racy reads are _permitted_ , so that writers of such things know that what they write may be subject to racy reads.\n\nRalfJung:\n\n> But deref'ing an `undef` pointer is UB, yes.\n\nThen that doesn't seem like a useful model for racy reads, unless I'm missing something here.\n\nRalfJung:\n\n> SeqLocks (which can be implemented neither in C\n\nI feel like we're definitely talking past each other at this point. People do implement seqlocks in C, and they're used regularly in production systems, including the Linux kernel. Is this the kind of \"can't\" where it actually works just fine in practice but compilers don't guarantee it despite that? I can appreciate the desire for clearer models and paths to support, but I think there's value in acknowledging things that do work in practice and are used in practice.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}