`MaybeInvalid<T>` - separate concepts of uninitialized memory and invalid values

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.

Also, 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.

However, 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.

To learn more about values and representation, here's a talk I gave last year at RustWeek:

MiniRust: A core language for specifying Rust - Ralf Jung