My impression was that there was some kind of optimization in LLVM that relied on being able to assume values were never undef[0], which is why undefined memory access was always illegal in Rust[1].
Putting that aside, a deliberate "read uninitialized memory with bounded UB" primitive like freeze would only work for types where all possible bit patterns are valid. So no freezing chars[2], references, or sum types. And any transparent wrapper type that has invariants - like, say, slices, vecs, strs, and/or range-restricted integer types - would see them utterly broken when frozen. I suppose you could define some operation to "validate" the underlying bit pattern, but I'm not sure if that would defeat the point of reading uninitialized memory.
[0] LLVM concept that represents uninitialized memory, among other things.
[1] I believe a few other unsafe Rust concepts are actually leaky abstractions around LLVM things
[2] Rust's char must hold valid UTF-8 and will UB if you stick surrogates in there
Putting that aside, a deliberate "read uninitialized memory with bounded UB" primitive like freeze would only work for types where all possible bit patterns are valid. So no freezing chars[2], references, or sum types. And any transparent wrapper type that has invariants - like, say, slices, vecs, strs, and/or range-restricted integer types - would see them utterly broken when frozen. I suppose you could define some operation to "validate" the underlying bit pattern, but I'm not sure if that would defeat the point of reading uninitialized memory.
[0] LLVM concept that represents uninitialized memory, among other things.
[1] I believe a few other unsafe Rust concepts are actually leaky abstractions around LLVM things
[2] Rust's char must hold valid UTF-8 and will UB if you stick surrogates in there