1. 22

  2. 5

    Interesting proposal, though it makes me wonder about something. Full Disclosure up front: my primary languages are C, Haskell and Lua; I’ve tried Rust numerous times and found it annoying/unusable enough that it will likely be a while before I take another serious look at programming in it. Having said that, programming language and library design is still something I find quite interesting.

    I remember early on in Rust’s creation, many of the proponents of the language wanted to clean up some of C++ (and, by extension, C)’s mistakes. One of the things that I heard talked about a lot was #ifdef soup for platform/os support.

    Recgonizing that I do not have a proposal for a better way of doing platform-portability, is this proposal not just a reversal of that stance and an adoption of the equivalent mechanic?

    If not, then what am I missing? Is rust’s cfg somehow inherently better than the CPP’s #ifdef (more than just being in Rust’s macro system rather than a preprocessor)? If so, was this digression just a mistake/red herring (there’s nothing wrong with that, by the way—everyone makes mistakes); or something else?

    1. 11

      I don’t think it’s a reversal of Rust’s previous stance. The current way of achieving portability in Rust is by putting platform-agnostic things in the stdlib, etc. This doesn’t change that.

      I’m not very clear what “digression” you’re talking about.

      Rust has always had cfg, and Rust libs have always used it for portability.

      What this is proposing is that the stdlib should:

      • work well if you turn off certain components (e.g. threads)
      • turn off components which aren’t supported on a given platform.

      Before, you simply couldn’t use the stdlib for these platforms.