Idea / Pre-RFC: Null-free pointer and Zeroable reference
You might have a chance of adding new variants of a few functions in the ptr module (e.g. read, write or copy_non_overlapping) which allow null without volatile semantics. Since these couldn't easily be provided by third party crates and wouldn't impact the language at large.
You could then implement your own abstractions on top of these in a third-party crate to make these use-cases easier and safer.
But I don't see your higher impact proposals, like allowing ordinary pointers to dereference null or new reference types in core happening.
I think adding read_memory and write_memory to core::ptr like this should be enough:
pub const unsafe fn read_memory<T>(src: *const T) -> T;
pub const unsafe fn write_memory<T>(dst: *mut T, src: T);
Their semantics would be similar to those of volatile, but without the elision/reordering guarantees. Something similar to this:
When a
memoryoperation is used for memory inside an allocation, it behaves exactly likeread/write.Memory operations, however, may also be used to access memory that is outside of any Rust allocation. In this use-case, the pointer does not have to be valid for reads/writes. Here, any address value is possible, including 0 and
usize::MAX, so long as the semantics of such a read/write match those of ordinary memory access on the target hardware. The provenance of the pointer is irrelevant, and it can be created withwithout_provenance. The access must not trap.
(I'm sure the semantics as written above don't quite work. But they should give the right idea. Somebody with a better understanding of the rust memory model than me would need to specify this)
- Unlike
*_volatileor inline asm, these could beconst, though they'd still need to panic when operating outside an allocation at compile-time. copy,copy_nonoverlapping,replace, etc. can easily be implemented on top of these in a these in a third-party crate
Discussion in the ATmosphere