It sounds like we’re considering a future
std that will be covered in
#[cfg]s to provide a reasonable API to almost every major target platform (which sounds pretty nice to me). For the minor targets is an aversion to forking
std still going to be reasonable after
cargo eats and gains the powers of
Also, is there anything stopping us re-using the existing
#![no_std] mechanism for optionally ‘delegating’ lang items? As in:
// in `std`:
#[cfg(feature = "no_default_panic_fmt")]
extern "C" fn panic_fmt(...);
Although, that has the problem (as do a bunch of solutions) that
std needs to know ahead of time what’s likely to need to be overridden.
Ideas like @matthieum above make me want Rust to have a ‘real’ module system with the ability to reach in and swap out parts of another crate, which would allow something weird and dangerous like this:
extern crate mod std::io::thread = mod my_custom_thread_mod;
But that’s a whole pile of new problems to deal with.
On that note, like @Alfriadox I would like to help! I’ve tried in the past to do a bare-bones IO-and-alloc port of
std to a hypervisor environment which I think hits the ‘fourth-tier target’ category, if that’s relevant.