{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaj3r2qqxmrk6tb5dy545mse3l6opggc36y5dhihh4f3rnuxmspnu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mn5y4ja3nk72"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289?page=2#post_37",
  "publishedAt": "2026-05-31T15:14:52.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "newpavlov:\n\n> It's not like your \"correctness argument\" is formally verifiable either,\n\nOh it definitely is.\n\nnewpavlov:\n\n> Nah. I am more of practitioner and the practice shows that my line of reasoning works.\n\nI am sure I can come up with counterexamples (EDIT: to the general approach of allowing the asm story to predict the future). But then you'll dismiss them as artificial.\n\nObviously for code you write you get to choose whatever tradeoffs you prefer for how thorough you want to be with your correctness arguments. But for project-official guidance I think we should have pretty high standards.\n\nFWIW, I think the reason that \"seqlock with inline asm for the data reads and writes\" works in practice is that there is another story, one that actually works in my framework (assuming a language extension to Rust that we'll hopefully get one day): consider those accesses to be relaxed bytewise atomic. I don't know if your intended implementation uses inline asm for both the read and the write path, but if it does, then I'd say your code is correct, just your story / correctness argument isn't.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}