Is cfg-if going to be pulled into std?

libs
#1

cfg-if seems strictly superior to cfg!. Because instead of generating dead code, it doesn't get included in the first place. (Hence it can be used for platform/os specific things).

While cfg-if is already one of the top 10 crates and is maintained by the libs team, it really seems like the sort of thing that should be in std.

4 Likes
#2

cfg-if uses #[cfg(...)], not cfg!(...).

#3

Isn't cfg-if better than #[cfg(...)]? At least I was told that it can even be used to gate experimental syntax from the parser, which is not possible with #[cfg(...)].

For this reason, and also because cfg-if is just extremely generally useful but pulling in a crate for this seems a bit too much, I'd very much like to see it in the standard library. :slight_smile: Also see:

Seeing that just landing a PR did not work, this probably needs an RFC.

2 Likes
#4

I'd also love to see something like this in stdlib. Just from personal experience, I've removed it as a dependency from one of my crates solely because it was an unnecessary dependency — the extra sugar wasn't worth its weight. I would definitely switch back (after a bit of time) should it land in stdlib.

2 Likes
#5

I also think it would be useful, and took a look at some of the discussion and saw that gnzlbg implemented match_cfg, which I haven't seen before. It requires more vertical space compared to nested else if clauses, but has some potential. I'm wondering if there has been any discussion of trimming some of the punctuation and syntax. For example, remove the repeating cfg like:

match_cfg! {
    (target_os = "vxworks") => {
        mod vxworks;
        pub use self::vxworks::*;
    }
    unix => {
        mod unix;
        pub use self::unix::*;
    }
    windows => {
        mod windows;
        pub use self::windows::*;
    }
    (target_os = "cloudabi") => {
        mod cloudabi;
        pub use self::cloudabi::*;
    }
    (target_os = "hermit") => {
        mod hermit;
        pub use self::hermit::*;
    }
    (target_os = "wasi") => {
        mod wasi;
        pub use self::wasi::*;
    }
    (target_arch = "wasm32") => {
        mod wasm;
        pub use self::wasm::*;
    }
    all(target_vendor = "fortanix", target_env = "sgx") => {
        mod sgx;
        pub use self::sgx::*;
    }
    _ => {
        mod unsupported;
        pub use self::unsupported::*;
    }
}

It looks like the cfg_match crate does something similar. Certainly a few options to explore.

3 Likes
#6

I'd be a big fan of cfg-if being a first-class part of the Rust language. It was #3 on my handwavy calculation of best candidates for 3rd party crates that should get folded into the language itself, after matches (now integrated!) and atty.

2 Likes
#7

Would be nice if you did a fresh take on your list, too!

3 Likes
#8

I like functionality of cfg-if but I like it to have first-class support and syntax: no unnecessary indentation.

rustfmt doesn't format module declared in cfg-if.

3 Likes
#9

This is very nice, and much nicer than cfg_if IMO, although ideally it would support both exprs and items like how cfg_if does in newer versions.

This is probably possible, I did something similar in the past that only supported expressions (and was exclusively for cfg(target_feature) https://github.com/thomcc/bad3d/blob/master/t3m/src/macros.rs#L25 (The implementation is really awkward, sure, and can only reasonably work for expressions as it is...)

Either way, something like this in libcore that works for both cases would be ideal.