That's not true. Apart from the padding bytes, which would indeed need to be initialized, and
mem::uninitialized, which is just plain evil, Rust doesn't allow anyone to touch or point to uninitialized stack memory, not even unsafe code. It's statically prevented by the compiler.
Heap allocations are a non-issue because even if LLVM itself has special handling for the
malloc function, and even if LTO makes those
malloc calls bubble up all the way from the allocator crate to the consumer code (both very possible), all you have to do is to alias the function under a different symbol name. Then it's just an extern function that returns a pointer, no special considerations involved.
Ah, right! That would be indeed very helpful.
Please don't. It's bad enough as it is, that Rust isn't fully specified separately from implementation. It makes it harder to understand the language, and writing non-trivial code with borrows is already basically "make random changes until it compiles".
I never, I repeat, never, suggested that heap and stack should be treated differently. I said previously that @rkruppe is attacking strawmen and I stand by that sentiment.
It could make it more clear to separate the two conflated concepts. For the purposes of discussion, let's call them "undefined memory" and "not-initialized memory" (to disambiguate from "uninitialized").
"undefined memory" is the concept that leaks from the LLVM level, it's the memory that is considered uninitialized by LLVM, and reading it is UB as per LLVM's rules. On Rust level, this maps exactly to padding bytes and
std::mem::uninitialized(), and nothing more, assuming LLVM is disavowed of its knowledge about what is heap allocation (as explained earlier).
"not-initialized memory", on the other hand, is the rust concept of uninitialized memory (https://doc.rust-lang.org/nomicon/uninitialized.html).
"undefined memory" is "not-initialized memory" by definition, but the opposite doesn't hold. "not-initialized memory" which is not "undefined memory" is unsafe to read, but is not necessarily UB.
Now that the language is established, it should be clear that it's possible for heap allocations to be "not-initialized memory", while not being "undefined memory". For the programmer, this is no more of a concern than the current definition of uninitialized memory. The argument that you would somehow need to care about the distinction is completely unfounded... if you can write unsafe code today without freaking out about uninitialized memory, you can do it just the same without freaking out about "undefined memory". In fact, you can hold on to your current intuition. Anything that's legal today would be legal with my suggestion. It would just make more code legal, including some cases that unexperienced programmers intuitively expect to be correct, but are in fact UB by current definition.