Idea / Pre-RFC: Null-free pointer and Zeroable reference

Your read_memory / write_memory proposal in #93 was genuinely helpful and I appreciated it. However, under Phase I, ptr::read / ptr::write themselves would become valid at 0x0 which means the separate functions would be redundant rather than complementary. This isn't a rejection of your idea; it's that the two approaches solve the same layer differently, and if Phase I lands, the existing APIs already cover what read_memory was designed to do.

CodesInChaos:

The "soundness issue" is that I'm using a dummy implementation for the new core::ptr functions I proposed.

// library/core/src/ptr/mod.rs:1546-1569
pub const unsafe fn replace<T>(dst: *mut T, src: T) -> T {
        // ...
        mem::replace(&mut *dst, src)
    }
}

Uhh... I think we have a divergence here - I meant that core itself relies on non-zero reference internally, which was the root of rust#138351. I didn't meant your dummy impl, sorry about the misunderstanding.

CodesInChaos:

It is an excessive solution, since the benefits are so small. The use-cases you address are extremely rare, and already have usable workarounds today. And in the end, Rust doesn't have to be usable for every single application.

To be clear: The Rust Core Team explicitly stated that embedded devices (which are no_std) are one of 4 important domains and stated to make it a first-class target.

• Rust's 2018 roadmap | Rust Blog
• Announcing the Embedded Devices Working Group

And the environments in question are not edge-cases, they're the highest-stakes subset. The Vorago VA108xx in the OP is a radiation-hardened MCU literally embedded in satellites (Astranis DemoSat-2, TechEdSat-8 CubeSat), and the workaround it was forced into (inline assembly and volatile API) is a direct violation of safety standards.

Anyway, I don't think we disagree on as much as it might seem - your read_memory / write_memory proposal came from recognising the same gap and I think your proposal stands on its own merit even if my RFC never lands. Where we differ is on scope, and I think that's better resolved through discussion in a formal RFC than here. I'd welcome your contribution there.