Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cfg meta variables #831

Open
alexcrichton opened this issue Feb 11, 2015 · 2 comments
Open

cfg meta variables #831

alexcrichton opened this issue Feb 11, 2015 · 2 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@alexcrichton
Copy link
Member

It's quite often that a cfg directive in an attribute becomes fairy complicated when support for more platforms are added. Even worse, a cfg block is then often duplicated among many locations to configure off different items.

The thread_local/mod.rs file is a good example of the amount of duplication.

It would be nice to have something like the following

#![cfg_shortcut(foo, any(super, long, clause))]

#[cfg(foo)] ...
#[cfg(not(foo))] ...

Here the clause any(super, long, clause) would be shortened to the identifier foo which could then be used elsewhere. In general it would just be nice to make these long cfg directives much shorter and less error prone to copy-paste.

@blaenk
Copy link
Contributor

blaenk commented Feb 13, 2015

Yeah this would be nice. This and bounds aliases from #804 should give us a more complete aliasing toolkit.

@lambda-fairy
Copy link
Contributor

If we expand macros within attributes, then this feature would drop out as a special case.

For example:

macro_rules! foo {
    () => (any(super, long, clause))
}

#[cfg(foo!())] ...
#[cfg(not(foo!()))] ...

Users wouldn't need to learn special syntax either -- just apply their existing macro knowledge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants