we could implement same function for different target by cfg

[lygstate]

for example, alloc for webassembly bare mental (powerfull, microcontroller) and real OS are different story, but we all need the alloc function, can we provide a single function for all of that? Do the same thing with hashmap and all the basic datastructure for pure rust system, and for IO, and asynchronous IO also need a single interface for all.

[jethrogb]

@lygstate I'm not sure what you're proposing. Isn't this exactly how things are implemented in std right now?

[lygstate]

@jethrogb At least now, std can not used in WebAssembly & MCU(embbeded, bare mental) environement. I hope std could be directly used any where.

[jethrogb]

I hope std could be directly used any where.

Yes, that is the goal of this working group. See https://github.com/rust-lang-nursery/portability-wg/blob/master/README.md#vision

Do you have a concrete proposal that is different from how things are currently done?

[lygstate]

@jethrogb That's great.

[lygstate]

@jethrogb Still have a problem, when bare-metal,

} else {
    compile_error!("libstd doesn't compile for this platform yet");
}

Do std have a option for bare-metal?

[lygstate]

cfg_if! {
    if #[cfg(unix)] {
        mod unix;
        pub use self::unix::*;
    } else if #[cfg(windows)] {
        mod windows;
        pub use self::windows::*;
    } else if #[cfg(target_os = "cloudabi")] {
        mod cloudabi;
        pub use self::cloudabi::*;
    } else if #[cfg(target_os = "redox")] {
        mod redox;
        pub use self::redox::*;
    } else if #[cfg(target_arch = "wasm32")] {
        mod wasm;
        pub use self::wasm::*;
    } else {
        compile_error!("libstd doesn't compile for this platform yet");
    }
}

There is no target for bare-metal.

[IsaacWoods]

@lygstate You fundamentally can't use std on bare-metal. You should be using core (and alloc if you can provide your own virtual memory manager). Look at this to get started.

[lygstate]

@IsaacWoods Yeap, I know that:(

[le-jzr]

@IsaacWoods I don't see anything fundamental about it. It's a restriction caused by certain implementation details, not a fundamental truth.

[lygstate]

@le-jzr I agreed, using no_std & core & alloc are really frustrating.

[jethrogb]

@lygstate I appreciate your interest in our work. We definitely want to make more of std available even in environments where not all functionality available.

That said, you're not really pointing out a specific feature you're missing nor a concrete idea someone can work on. The core of your message appears to be that we're not done yet. This is true, in fact, we're just getting started.

[lygstate]

@jethrogb I target are porting rust - WASM interpreter to bare-metal environment, that's too big, so I'll focus on small target. I would help to do some patches in std to speed up the progress. Any sugguestion?

[jethrogb]

Our initial focus is #1 and in particular https://github.com/rust-lang-nursery/portability-wg/issues/1#issuecomment-373790342 . I'd also suggest joining the IRC channel: #rust-portability on irc.mozilla.org to coordinate.