{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibjft7q4nnuf6sz47xyuf25pstcpxz2ub3eggstx6sh7j6dqltipa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mhfuokeai5y2"
  },
  "path": "/t/maybeinvalid-t-separate-concepts-of-uninitialized-memory-and-invalid-values/24087#post_6",
  "publishedAt": "2026-03-18T18:08:59.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "MiniRust: A core language for specifying Rust - Ralf Jung"
  ],
  "textContent": "This proposal seems to be based on a misunderstanding about how uninitialized memory factors into the Rust validity rules. There is no special rule in Rust that says uninitialized memory is inherently forbidden, or anything like that. It's just a state memory can be in. Some of our types require memory to be in certain states. For instance, `i32` requires memory to be in an arbitrary initialized state, while `bool` requires memory to be either `0x00` or `0x01`. _Those are the same kind of requirement._ We don't say \"first of all, the `bool` must be initialized, and then also it must be `0x00` or `0x01`\". Instead we just have a set of valid representations, done. This distinction you try to draw between \"invalid value\" and \"non-fixed value\" _does not exist_. So, your proposal suggests to add a fundamentally new concept to the language, a new distinction that we currently do not have or need. Why do you think we should add more concepts? Things are already complicated enough, we don't need even more concepts.\n\nAlso, you need to be careful with terms like \"fixed value\". If the memory contents are `0xFF`, and the type is `bool`, then this memory _has no value_ at that type (it is \"invalid\" at the type), and therefore it also makes no sense to talk about the value being \"fixed\". I assume what you mean is that the underlying _representation_ is \"fixed\" in the sense of being fully initialized.\n\nHowever, that brings us to the next question. What does that type even do when there is padding? `(u8, u16)` allows the padding byte to be uninitialized. Does `MaybeInvalid<(u8, u16)>` somehow require the padding byte to be initialized? That would make no sense at all. But if you allow it to be uninitialized then the description of `MaybeInvalid` makes little sense.\n\nTo learn more about values and representation, here's a talk I gave last year at RustWeek:\n\nMiniRust: A core language for specifying Rust - Ralf Jung",
  "title": "`MaybeInvalid<T>` - separate concepts of uninitialized memory and invalid values"
}