IO traits, HashMap, HashSet for no_std


#1

I’m announcing the core_io and core_collections crates, bringing the IO traits and the HashMap and HashSet data structures to the no_std world. (Note that core_collections has an optional dependency on the rand crate which poses some problems, you might want to supply your own, or follow rand PR #108)

The code in the crates is mostly just copied directly from the rust source with some straight-forward deletions. The crates have a build script that make sure that you will be using the same source that was used for the libstd version that comes with your compiler. I intend to set up some automation to automatically update the crate for every new nightly version, but for now it has to be done by hand. Ping me (or submit a PR) if you need a newer version.


RustConf: core/no_std meeting
#2

Why does it matter whether the code in the crate matches the version of libstd distributed with the rustc you’re using? It’s not like a version of the Read trait written in stable Rust needs to be changed when a new version of the compiler is released.

It looks like the intent of these crates is that they depend on liballoc, but not on libc in general? You probably want to document that explicitly, especially for core_io (since you could write a version without that dependency).

It would be nice to generate documentation for these crates so someone can tell at a glance exactly what they include.


#3

For stable Rust, yes. But in nightly, unstable functionality can come and go with little warning. I went for a least-surprises approach where if something exists in the documentation of your compiler, it will also exist in this crate, and it will work the same way.

I’ll look into adding a feature to remove the dependency on collections/alloc for core_io. But things like BufReader, Write::write_fmt and Read::{read_to_end,read_to_string} do depend on them of course. Also io::Error…

The documentation is littered with references to std and I found it too much effort to fix every example to generate documentation which basically already exists. Do you think it would be sufficient to add a warning to the main page about this? Also, of which version should the documentation be generated?


#4

A list of the types exposed by the crate would suffice for most purposes. (It might be possible to write a script to automatically fix up the documentation, but I have no idea how much work that would be.)

I hadn’t really thought about it that way, but it makes sense… you also don’t have to worry about backporting bugfixes.


#5

Another note on this: you’re probably thinking about supporting stable, but that’s not going to happen because the source makes use of a lot of unstable features (question mark operator comes to mind).


#6

Well, I was sort of thinking about supporting stable… but more practically, I was thinking of scenarios where someone doesn’t want to tie themselves to liballoc.

I hadn’t really considered the problem that the implementation of libstd was using nightly-only features, as opposed to the API.


#7

For now I’m just hiding a bunch using CSS.


#8

Very nice! I’ve been considering writing my own HashMap type for a while because it wasn’t supported in no_std. One nice feature you could add however is the ability to make the rand dependency optional. If rand is disabled then you would just #[cfg] out the RandomState type and force people to specify a hasher every time they create a HashMap.


#9

Yes, I was thinking about this, I originally thought this was going to be a pain because of definitions such as struct HashMap<K, V, S = RandomState> (which are not easily cfg-able) but there’s not that many of those.


#10

The latest version of core_io includes alloc/collections features.


#11

The latest version of core_collections includes the rand feature.