Make standard library dependencies pluggable

[sffc]

In order to reduce code size when shipping binaries to other environments, such as WebAssembly, it may be desirable to give a way to leverage the environment's standard library instead of building the Rust version into the OmnICU binary.

For example, JavaScript has a Map type. If we build OmnICU to target WebAssembly, it would be nice if OmnICU could import JavaScript Map instead of shipping hashbrown.

CC @kripken

[kripken]

In general this sounds good for code size, but doing it on a core data structure seems risky for perf due to many wasm<->JS calls (imagine iteration on a map).

cc @alexcrichton @fitzgen who might have thoughts or be aware of relevant work.

[Manishearth]

The cost tradeoffs are definitely weird there, but we could potentially have this cfg-based

[fitzgen]

It is possible to do this, and I would suggest making a crate which has as similar an api as std::collections::HashMap or whatever as possible. No one has published anything like this yet, afaik, but not because it isn't possible. Yes, cost trade offs, as mentioned above. Also implies depending on some extra tool to hook up imports of the js map type (eg wasm-bindgen and js-sys)

[sffc]

Action: this should be discussed as part of the Rust Style Guide (#12).

[sffc]

This issue is not immediately actionable until we start hooking up FFI and WebAssembly. I'm documenting in the style guide as part of #77 to favor alternatives to HashMap where possible. We should revisit this issue when more code is written and evaluate the cost/benefit tradeoff.

[sffc]

We now have LiteMap (#496), which solves the HashMap problem. It's not clear that there are any other major areas where we would need this functionality. I will therefore close this issue as obsolete.