TL;DR: This post proposes to deprecate the
std facade, instead having a
std that uses target- and capability-based
cfgs to control API
Portability is extremely important for Rust, in two distinct (and sometimes competing!) ways:
Rust should be usable in almost any environment, and ideally much of the ecosystem would be as well.
Rust should be low-friction when writing for “mainstream” platforms (32- and 64-bit machines running Windows, Linux, or macOS).
An example of the tension between these two goals is handling allocation:
Some targets for Rust do not support allocation natively, so Rust must at least have a “mode” in which no allocation is assumed.
For “mainstream” applications and platforms, we want to assume not only that allocation is available, but that running out of memory is a catastrophic failure. Those assumptions are reasonable for a huge amount of software, and making them greatly reduces the friction to writing Rust code.
We’ve been slowly evolving a set of answers to this kind of question, and part of the point of this blog post is to step back and try to give a unifying vision for how to approach portability issues in Rust.
Read the rest of the post and leave comments here if you want to be involved!