Allow &&, ||, and ! in cfg

[jhpratt]

About as simple as it gets.

Rendered

[clarfonthey]

I think that a feature != "string" syntax as an alternative to not(feature = "string") would be a nice addition here. !(feature = "string") feels weirder to me than not(feature = "string"), honestly.

[jhpratt]

The problem I see with feature != "foo" is that it could plausibly be interpreted as "any feature other than foo".

[clarfonthey]

That interpretation feels like a stretch to me, but it's also understandable. Perhaps a feature("string") syntax might be a bit more natural with !feature("string"), and also extensible to feature("string", "other string").

[jhpratt]

Updated the following:

• !feature = "foo" is no longer permitted. Negation can be followed by further negation, parentheses, a single identifier (so #[cfg(!unix)]), and any function-like predicate.
• &/| added as alternative to &&/||
• feature != "foo" added as alternative to !(feature = "foo")
• added table with examples
• linked to operator precedence for expressions for clarity

[RalfJung]

I think that a feature != "string" syntax as an alternative to not(feature = "string") would be a nice addition here. !(feature = "string") feels weirder to me than not(feature = "string"), honestly.

The problem here is that = in a cfg expression really means "contains", since feature (and also all other cfg variables) are really sets of strings, not just strings. So != would then mean "does not contain".

= is at least a different symbol from == so there's some hint that the semantics might be different, though it's not a very clear hint at all. != would exactly match expressions so there's not even a hint that the semantics are different.

[m-ou-se]

I read #[cfg(feature = "asdf")] similar to how I read things like #[serde(default = "asdf")] or #[link_name = "asdf"]: The = syntax is used as a key-value pair, like in all attributes.

As mentioned above, feature = "asdf" is not at all like a Rust expression. It doesn't behave like a = expression (it's not an assignment). It doesn't behave like an == expression (it doesn't check equality either). There is no variable/concept named feature that is compared to anything.

It isn't even commutative: #[cfg("asdf" = feature)] doesn't work.

Using key = "value" syntax makes sense as it matches the syntax for all other attributes. But I don't think it makes much sense to take && and || from Rust expressions and trying to force them into attribute syntax. The result feels weirdly inconsistent, with things like !(feature = "asdf") not being the same as feature != "asdf", and so on.

If we do want to make cfg() take something that looks like an expression, we should also change the feature = "asdf" syntax to something that fits a Rust expression. E.g. #[cfg(has_feature("asdf") && has_target_feature("asdf"))].

[m-ou-se]

Let's look at a real world example:

#[cfg(any(target_os = "android", target_os = "linux", target_os = "emscripten", target_os = "freebsd"))]

This proposal would allow rewriting that as:

#[cfg(target_os = "android" || target_os = "linux" || target_os = "emscripten" || target_os = "freebsd"))]

Which looks a bit nicer.

But instead of just replacing any() by a series of ||, I think we can do much better without giving up on the key = value syntax with something like:

#[cfg(target_os = "android" | "linux" | "emscripten" | "freebsd")]

I don't want to derail this thread with alternative proposals, but I do think that && and || is not getting us that much. If we go in that direction of making cfg() accept expression-like syntax, then we might be closing ourselves off from improvements to the key = value syntax that might serve the actual use cases better.

[RalfJung]

The result feels weirdly inconsistent, with things like !(feature = "asdf") not being the same as feature != "asdf"

How would they not be the same? The RFC, I think, intents for both of these to mean the same thing: the feature variable does not contain "asdf".

[m-ou-se]

!(feature = "asdf") would work, while feature != "asdf" would be an error.

[RalfJung]

Ah. That seems entirely consistent to me, it's = and not == after all.

I like target_os = "android" | "linux" | "emscripten" | "freebsd" but it doesn't when you need to look at more than one key.

[m-ou-se]

My point is that we need tot look at real world examples of code we're trying to simplify.

For example, quite often, any() is used with the same key, such as when selecting for a list of different operating systems. We should optimize the syntax for patterns that occur in actual code.

Large cfg() attributes can be very confusing. But replacing any() and all() by || and && isn't making it much better. Large boolean expressions will still be confusing, especially if their syntax is a hybrid of expressions and (key=value) attribute syntax with inconsistent precedence and operator meaning.

[m-ou-se]

Rust parses feature = "asdf" && unix as feature = ("asdf" && unix), not as (feature = "asdf") && unix.

One might argue that = in attributes is different, but how would we expect an attribute proc macro to parse this today?

#[my_attribute_macro(expr = a && b, expr2 = c || d)]

I would assume it interprets that as two key = value pairs with the values being a && b and c || d. (It's up to the proc macro to decide, this is what you get if you parse it with a Rust expression parser.)

So even in an attribute, I'd argue that && should have higher precedence than the key=value operator. But that's the opposite of what this RFC proposes.

[programmerjake]

maybe embrace that they are sets and allow using "abcd" in feature instead of feature = "abcd"? though then that makes me think we should have named it features.

[kpreid]

Large cfg() attributes can be very confusing. But replacing any() and all() by || and && isn't making it much better.

I would go so far as to argue that any() and all() are better for formatting. Binary operators used repeatedly have an awkward indentation problem. Currently, rustfmt produces:

#[cfg(any(
    feature = "foo",
    feature = "bar",
    feature = "baz",
    feature = "quux",
    feature = "magic",
    test
))]

Whereas a similar boolean expression is less regular and longer:

something(cfg(
    feature == "foo"
        || feature == "bar"
        || feature == "baz"
        || feature == "quux"
        || feature == "magic"
        || test,
));

(And there are probably even messier cases to present with && and ! but I don't feel up to producing an illustrative example right now.) I won’t say that I haven’t wished for conventional binary operators in simple cases, but switching to them completely would have significant disadvantages (as would having a mix of both as standard style, simply due to having two things to learn and the choice of which one to use).

On the other hand, supporting feature = "foo" | "bar" has the inherent advantage of making the expression shorter and less repetitive, while still aligning with existing Rust syntax (patterns). It does raise the question of “why can’t I just write cfg(windows | unix)”, which, if also supported, would have a precedence problem — i.e. you have to either allow or prohibit cfg(feature = "foo" | bar), and if allowed, bar could be misinterpreted as a merely-unquoted value string.

[kennytm]

So even in an attribute, I'd argue that && should have higher precedence than the key=value operator. But that's the opposite of what this RFC proposes.

GitHub really needs a 😢 emoji.

To be compatible with this existing syntax, it means all key = "value" cfg has to be wrapped in parenthesis:

#[cfg((target_os="linux") && (target_arch="x86_64") && (target_env="gnu") && !debug_assertions)]

[kennytm]

I would go so far as to argue that any() and all() are better for formatting. Binary operators used repeatedly have an awkward indentation problem.

...

Whereas a similar boolean expression is less regular and longer:

...

(And there are probably even messier cases to present with && and ! but I don't feel up to producing an illustrative example right now.) I won’t say that I haven’t wished for conventional binary operators in simple cases, but switching to them completely would have significant disadvantages (as would having a mix of both as standard style, simply due to having two things to learn and the choice of which one to use).

Yes the formatting is strange, but I'd argue that the binary operator makes the cfg more readable for reviewers because you can be sure it is a chain of any rather than all at the first glance (spot the difference:

Existing syntax	#[cfg(any( feature = "foo", feature = "bar", feature = "baz", feature = "quux", feature = "magic", test ))]	#[cfg(all( feature = "foo", feature = "bar", feature = "baz", feature = "quux", feature = "magic", test ))]
This RFC	#[cfg( (feature = "foo") || (feature = "bar") || (feature = "baz") || (feature = "quux") || (feature = "magic") || test )]	#[cfg( (feature = "foo") && (feature = "bar") && (feature = "baz") && (feature = "quux") && (feature = "magic") && test )]
Alternative proposal	#[cfg(any( feature = "foo" | "bar" | "baz" | "quux" | "magic", test, ))]	#[cfg(all( feature = "foo" & "bar" & "baz" & "quux" & "magic", test, ))]

[SabrinaJewson]

cfg(any()) and cfg(all()) are very useful, often in macros, as always-false and always-true cfg values respectively. This RFC does not need to supplant all existing use cases of all and any, but it does seem weird to replace most things except this one edge case.

[Jules-Bertholet]

cfg(any()) and cfg(all()) are very useful, often in macros, as always-false and always-true cfg values respectively.

rust-lang/rust#131204

[joshtriplett]

@m-ou-se wrote:

If we do want to make cfg() take something that looks like an expression, we should also change the feature = "asdf" syntax to something that fits a Rust expression. E.g. #[cfg(has_feature("asdf") && has_target_feature("asdf"))].

Agreed completely. I don't think it would be ambiguous here to reuse "feature" without adding "has_": cfg(feature("asdf")). And this would also be consistent with other parts of cfg syntax.

[kennytm]

I don't think it would be ambiguous here to reuse "feature" without adding "has_": cfg(feature("asdf")). And this would also be consistent with other parts of cfg syntax.

Technically this change of syntax will conflict with the cfg_version feature but since it is unstable it is fine...? (plus can't use version="x" on stable at all, it somehow triggers cfg_version too)

#![feature(cfg_version)]
fn main() {
	dbg!(cfg!(version("1.69.0")));
	dbg!(cfg!(version("2.0.0")));
	dbg!(cfg!(version = "1.69.0"));
	dbg!(cfg!(version = "2.0.0"));
}

$ rustc +nightly --cfg 'version="2.0.0"' 1.rs
$ ./1
[1.rs:3:2] cfg!(version("1.69.0")) = true
[1.rs:4:2] cfg!(version("2.0.0")) = false
[1.rs:5:2] cfg!(version = "1.69.0") = false
[1.rs:6:2] cfg!(version = "2.0.0") = true

[jhpratt]

@camsteffen Is churn the primary (or even sole) concern? I think the 👍s on this PR show that there's unquestionably the desire for logical operators — it feels obvious imo.

[jdonszelmann]

I actually like @camsteffen's proposal a lot. It makes many scenarios simpler right now without changing ther original feature = name syntax. And the existing situation isn't so bad. And, if we feel like adding boolean operators later that still works!

[camsteffen]

@jhpratt Not just churn, but the fact of having two ways to express something and a split in the ecosystem of which one is used. The motivation may be to make things simpler by matching other syntax, but I think the reality is that it's increasing complexity with another thing to learn. I would be more open to it if I could snap my fingers and change all the code in the world to the new syntax. But I also agree with @kpreid that any/all is better with regard to formatting.

[Jules-Bertholet]

I would go so far as to argue that any() and all() are better for formatting. Binary operators used repeatedly have an awkward indentation problem…

Yes the formatting is strange, but I'd argue that the binary operator makes the cfg more readable for reviewers…

[…]

Alternative proposal

#[cfg(any(
    feature = "foo" 
        | "bar" 
        | "baz" 
        | "quux" 
        | "magic",
    test,
))]

#[cfg(all(
    feature = "foo" 
        & "bar" 
        & "baz" 
        & "quux" 
        & "magic",
    test,
))]

A little more indentation makes this look much better:

#[cfg(any(
    feature = "foo" 
            | "bar" 
            | "baz" 
            | "quux"
            | "magic",
    test,
))]

#[cfg(all(
    feature = "foo" 
            & "bar" 
            & "baz" 
            & "quux" 
            & "magic",
    test,
))]

[kennytm]

@Jules-Bertholet the default rustfmt will not use vertical alignment.

---

@camsteffen Rust isn't afraid of having multiple ways to express the same concept, we have for x in it {} vs while let Some(x) = t.next() {}; async fn f() -> R vs fn f() -> impl Future<Output=R>; fn g(a: impl Read) vs fn g<R: Read>(a: R) vs fn g<R>(a: R) where R: Read+, etc. Even your proposal it going to introduce #[cfg(feature = "name")] vs #[cfg(feature("name"))]. IMO "splitting the ecosystem" is FUD and is no ground to reject a proposal for Rust.

This proposed syntax #[cfg(key("val1" | "val2" | "val3"))] works well when everything involved has the same "key", but won't help when multiple "keys" are involved, e.g.:

	Exhibit A	Exhibit B
Existing code	#[cfg(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) ))]	#[cfg(any( unix, windows, target_os = "psp", target_os = "solid_asp3", all(target_vendor = "fortanix", target_env = "sgx"), ))]
This RFC	#[cfg(doc && ( (target_arch = "wasm32") && !(target_os = "wasi") || (target_vendor = "fortanix") && (target_env = "sgx") ))]	#[cfg(unix || windows || (target_os = "psp") || (target_os = "solid_asp3") || (target_vendor = "fortanix") && (target_env = "sgx") )]
key("value") only	#[cfg(all( doc, any( all(target_arch("wasm32"), not(target_os("wasi"))), all(target_vendor("fortanix"), target_env("sgx")) ) ))]	#[cfg(any( unix, windows, target_os("psp" | "solid_asp3"), all(target_vendor("fortanix"), target_env("sgx")), ))]
This RFC + key("value")	#[cfg(doc && ( target_arch("wasm32") && !target_os("wasi") || target_vendor("fortanix") && target_env("sgx") ))]	#[cfg(unix || windows || target_os("psp" | "solid_asp3") || target_vendor("fortanix") && target_env("sgx") )]

[RalfJung]

Oddly, my first reaction to those examples that I'd like to use "any" and "&&"... I can't really explain why. But I do feel like the use of infix operators makes it less clear that we are looking at a list of cases.

[SOF3]

Can we just have && and || without the ! part? ! is already too overused, and it gets worse when applied in #![] attributes. I don't want to see this in my code:

#![cfg(!windows)]

[jhpratt]

@SOF3 Realistically you wouldn't because there isn't much of a use case for that specifically. ! meaning "not" is nearly universal in programming languages.

[RalfJung]

For those that are curious about the "nearly" part: the large family of ML-based languages including OCaml use ! to mean "load from a reference" (that's a bit like * in Rust but not quite). "not" is written ~ in those languages (I think this is intended to be close to ¬, the typical logical symbol for negation).

[kornelski]

I really like this proposal. Not because it shortens some expressions, but because it's a step towards reducing the amount of unique microsyntaxes inside the Rust language.

[kornelski]

As for the = bikeshed, how about feature.name/target_os.wasi, pretending that it's a struct with bool fields for all the options.

[programmerjake]

As for the = bikeshed, how about feature.name/target_os.wasi, pretending that it's a struct with bool fields for all the options.

what happens when values aren't a simple number/identifier? e.g. --cfg=foo="abc def": https://rust.godbolt.org/z/bKfKGorbW

[kennytm]

As for the = bikeshed, how about feature.name/target_os.wasi, pretending that it's a struct with bool fields for all the options.

A feature name may consist of [_0-9\p{XID_Start}][-+.\p{XID_Continue}]*, and even the crates.io-restricted set is still [_0-9a-zA-Z][-+_0-9a-zA-Z]*. It would be very confusing for the parser to allow #[cfg(feature.c++20)].

Furthermore a custom config --cfg 'thing="!@#$%^&"' allows any string literal as the value (including empty string --cfg 'thing=""', which is distinct from --cfg 'thing'). I don't think the quotation marks should be omitted.

#[cfg(feature = "c++20")]
#[cfg(feature("c++20"))]
#[cfg(feature."c++20")]

[programmerjake]

I don't think the quotation marks should be omitted.

we could do something like TOML paths where you can omit the quotation marks if it's a valid identifier or number (equivalent to the corresponding quoted version) or you can have a string literal with any random text at all (except for commas since I think it's split into separate values using commas...).

so, with --cfg=a="123" --cfg=b="abc" --cfg=c="123-4,abc" that works with all of:

• cfg(a.123)
• cfg(a."123")
• cfg(b.abc)
• cfg(b."abc")
• cfg(c."123-4")
• cfg(c.abc)
• cfg(c."abc")

as well as all the existing cfg(a = "123") syntax.

[kornelski]

Without inventing new syntax (like c."abc") that isn't in Rust, access to non-identifier "fields" could be:

thing["#$%@!"]

For convenience, the thing.ident syntax could be supported too when the name is a simple identifier, similarly to JS where feature.foo and feature["foo"] are equivalent.

has_feature("foo") is also fine.

[RalfJung]

key("value") is not inventing new syntax.

[Urgau]

How would it interact with the target(os = "linux", ...) shorthand from RFC 3239?

[kennytm]

well it's being removed rust-lang/rust#130780

#[cfg(all(target_os = "linux", target_arch = "arm"))]
#[cfg(target_os("linux") && target_arch("arm"))]
#[cfg(target(os = "linux", arch = "arm"))]

[Urgau]

Last comments from T-lang members tend to the opposite, so probably going to stay.

[tmandry]

Things I'm quite sure I like:

• && instead of all(...). It's too difficult to find a visual distinction between all and any and I often miss it.
• feature("string") instead of feature = "string". This was already confusing to begin with.

Things I'm less sure of but still open to:

• || instead of any(...). We should probably allow it for consistency, but I do find myself agreeing with @RalfJung that it ends up looking nicer to use any(). The main thing for me is having a clear visual distinction between the two, as I said above, and we technically only need one operator to accomplish that.
• !. I think this will be much improved when combined with feature("string"). I like that it's "loud" visually, but most times it has to be used like !() which never feels that great.
• Incorporating pattern syntax. We might need to extend it beyond | to include &. This does seem like it could be a win, but it implies to me that we would want to unify these as far as we sensibly could. I'd want to discuss the possible implications of that in more depth.

[tgross35]

When deciding upon a pattern here, it's probably worth thinking about the standard library's close-to-stable cfg_match!. It would be great if the same syntax was usable in both cfg(...) and cfg_match!{ ... }.

[kennytm]

The problem adapting to cfg_match! is that a && b etc. are not valid :meta in a macro. This is not a problem of cfg_match! alone, any other decl-macro expecting #[cfg($cfg:meta)] will be affected

[joshtriplett]

Attempting to summarize the current state:

I think the current RFC proposing &&, ||, and ! would likely get a signoff.

|| has less strong support than &&, but seems important for consistency, and people will continue to have the option of writing any in any case where they consider it more readable.

---

I agree with the many comments saying that ! becomes even more useful if we add feature("...") and target_os("...") and similar. That seems worth writing up as a separate simple proposal.

| inside those patterns (target_os("..." | "...")) likewise seems useful, though it has less widespread support.

The combination of those two (function-style predicates and | inside them) seems like it would make a consistent proposal. I'd suggest leaving that in the "future work" of this RFC, and proposing it as an additional small RFC that complements this one.

---

I think != can be fully ruled out.

I also don't think there's been much support for &.

[joshtriplett]

@rust-lang/lang, shall we accept the RFC as currently proposed, for adding &&, ||, and ! to cfg syntax?

As currently written, the RFC defers all other potential additions to future proposals.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[jhpratt]

That is my understanding of the current state as well. If accepted, I will almost certainly follow up with a function-like feature("foo") proposal as a standalone RFC.

Thanks for moving this forward, Josh!