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 xargo
?
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.