Allow &&, ||, and ! in cfg
#3796
Conversation
ehuss
added
the
T-lang
|
I think that a |
|
The problem I see with |
|
That interpretation feels like a stretch to me, but it's also understandable. Perhaps a |
|
Updated the following:
|
The problem here is that
|
|
I read As mentioned above, It isn't even commutative: Using If we do want to make cfg() take something that looks like an expression, we should also change the |
|
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 #[cfg(target_os = "android" | "linux" | "emscripten" | "freebsd")]I don't want to derail this thread with alternative proposals, but I do think that |
How would they not be the same? The RFC, I think, intents for both of these to mean the same thing: the |
|
|
|
Ah. That seems entirely consistent to me, it's I like |
|
My point is that we need tot look at real world examples of code we're trying to simplify. For example, quite often, Large cfg() attributes can be very confusing. But replacing |
|
Rust parses One might argue that I would assume it interprets that as two So even in an attribute, I'd argue that |
|
maybe embrace that they are sets and allow using |
I would go so far as to argue that #[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 On the other hand, supporting |
GitHub really needs a 😢 emoji. To be compatible with this existing syntax, it means all #[cfg((target_os="linux") && (target_arch="x86_64") && (target_env="gnu") && !debug_assertions)] |
Yes the formatting is strange, but I'd argue that the binary operator makes the
|
|
|
|
|
@m-ou-se wrote:
Agreed completely. I don't think it would be ambiguous here to reuse "feature" without adding "has_": |
Technically this change of syntax will conflict with the cfg_version feature but since it is unstable it is fine...? (plus can't use #![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 |
|
The problem adapting to |
|
Attempting to summarize the current state: I think the current RFC proposing
I agree with the many comments saying that
The combination of those two (function-style predicates and I think I also don't think there's been much support for |
|
@rust-lang/lang, shall we accept the RFC as currently proposed, for adding As currently written, the RFC defers all other potential additions to future proposals. @rfcbot merge |
|
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
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. |
rfcbot
added
proposed-final-comment-period
|
That is my understanding of the current state as well. If accepted, I will almost certainly follow up with a function-like Thanks for moving this forward, Josh! |
|
First, thanks to @jhpratt for putting this together. The current syntax of Some thoughts: One, I agree with @m-ou-se that, on its own, the degree of improvement here is somewhat limited, with @RalfJung that Two, I'm certain that That's not directly part of this RFC, of course, but I think probably this RFC makes less sense if we're not headed in a direction like that, so I do maybe want to consider more of this together. Three, this RFC specifies an alternate precedence for @rfcbot concern uncomfortable-with-precedence-carve-out |
FWIW I find |
Yes; I have a similar intuition for it, and agree that it's natural in that way. I'm just not sure about putting this set-membership predicate in the same syntax space as arbitrary predicates, and thereby making it a breaking change to add any new such predicates. |
| | `feature="foo" \|\| feature="bar"` | `any(feature="foo", feature="bar")` | `\|\|` has lower precedence than `=` | | ||
| | `feature="foo" && feature="bar"` | `all(feature="foo", feature="bar")` | `&&` has lower precedence than `=` | | ||
| | `!feature="foo"` | _syntax error_ | `!` has higher precedence than `=`, which may be confusing, so we ban this syntax | | ||
| | `!(feature="foo")` | `not(feature="foo")` | use `()` for grouping | |
There was a problem hiding this comment.
(starting an inline discussion for brainstorming key = "val" syntax stemming from #3796 (comment))
FWIW I find
S(e)to be a quite natural way to represente ∈ S, but that is probably because of my background in type theory where sets are often modeled as predicates ("functions with return typebool", basically), and so asking "is this value in the set" is literally a function call.Yes; I have a similar intuition for it, and agree that it's natural in that way. I'm just not sure about putting this set-membership predicate in the same syntax space as arbitrary predicates, and thereby making it a breaking change to add any new such predicates.
Could we add a new named predicate for this? set(feature, "foo") is terse and could work, though I don't love that the intuition here would probably indicate a 1:1 mapping. contains or includes are probably how we would spell this on a collection, but I think contains(feature, "foo") sounds a bit worse than plural would be contains(features, "foo").
There was a problem hiding this comment.
I'll have an RFC together soon, though deciding what the syntax should be will definitely be better before it's fully written.
Random thought, which admittedly isn't very Rust-like, is feature?("foo"), along with feature?("foo" | "bar") and feature?("foo" & "bar"). There is some precedence in Ruby where ? means a function that returns a boolean.
There was a problem hiding this comment.
There is some precedence in Ruby where
?means a function that returns a boolean.
It comes from Scheme, which uses the same convention for predicates, e.g. odd?.
There was a problem hiding this comment.
To me the important effect of adding &&, etc. to cfg is making it more consistent with the regular Rust syntax, so that it's less of a second micro language within a language.
Using ? in cfg in a way that is different from regular Rust code would be just another version of the same problem of using = in cfg in a way that is different from regular Rust code.
feature("val") is not too bad. It's probably the tersest syntax that regular Rust code could implement for the same purpose.
For multiple values, maybe something like this:
feature(any("val1", "val2"))
This would also be implementable in a regular Rust syntax with a bit of generics.
There was a problem hiding this comment.
One potential issue is that feature(..) is currently used for enabling language features, whereas feature = ".." is used for checking crate features. Not really sure how to reconcile this, honestly, but worth pointing out that making the syntax closer to feature(..) may not be best.
There was a problem hiding this comment.
Rust typically uses foo() for getters and set_foo() for setters, and cfg() is a context that is querying the config rather than setting it, so to be this doesn't look like a setter.
has_feature() would be even clearer.
|
Simple Boolean operations are one thing, but what I’m really hoping for is the ability to compare values, something that’s quite common in C macros, like:
But in Rust, there’s currently no way to express this, which leads to some rather awkward workarounds. Right now, the values in Rust’s
|
|
@jmjoy That would fundamentally change what |
|
There have been proposals for key-value features, and I'd expect such a proposal to talk about how to use them in |
|
It would be nice if this RFC also specified a new |
That's a good point. This document should, I think, discuss the effect of this on macro fragment specifiers and propose solutions, perhaps using our guidance in #3531, if appropriate. @rfcbot concern discuss-effect-on-macro-fragment-specifiers |
|
Sure, things like |
Right now, the only thing they “need to work around” is
Footnotes
|
|
How common are macros that need to handle the internal part of Essentially, my argument is that this scenario is sufficiently uncommon that it is not worth the added language complexity for a rarely used macro fragment specifier. |
I just cited three examples. If you feel that defining an entirely new specifier is too much complexity, one alternative would be to re-use |
I meant in general, everyday code. Defining macros like that is not common, presumably, hence my question. My belief is that manipulating the contents of For what it's worth, |
|
Actually, I realized that |
|
See rust-lang/rust#145060 for previous discussion on
|
Increasingly I am thinking that this is probably the best solution. |
|
@rfcbot resolve discuss-effect-on-macro-fragment-specifiers |
|
About as simple as it gets.
Rendered