# \[Pre-RFC\] Cfg Attribute Alias

**URL:** <https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404>\
**Category:** language design\
**Created:** [April 27, 2018, 12:14am UTC](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404 "2018-04-27T00:14:23Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![kainino](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kainino/32/295_2.png) [@kainino](https://internals.rust-lang.org/u/kainino)\
**Post date:** [May 1, 2018, 6:20am UTC](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404/21 "2018-05-01T06:20:23Z")

</div>

Started writing this last night but it was too late to finish it up. BTW, there was also this [RFC for macro expansion inside proc macros](https://github.com/rust-lang/rfcs/pull/2320).

My main thought here is that it’s weird to special case “a cfg that is a combination of other cfgs” and “a derive that is a combination of other derives”. Shouldn’t we go up a level and say “an attribute that’s a combination of other attributes”? That is: `#![let my_attrib = #[cfg(foo)] #[derive(Clone)] ]`. (_not actually proposing this._)

I was actually going to go the same route of suggesting this be implemented via macros as well. Today we can already do it this way:

```rust
macro_rules! my_attrib {
    ($i: item) => ( #[cfg(foo)] #[derive(Clone)] $i )
}
my_attrib! { struct A; }

```

but what I would like to see is the ability to put macros in attribute position, like so (though this may not work in Rust’s actual AST order):

```rust
macro_rules! my_attrib { // or `macro_rules! #[my_attrib]`
    () => ( #[cfg(foo)] #[derive(Clone)] )
}
#[my_attrib!] struct A; // again, arbitrary syntax
// tiny change to today's macro syntax - just adds #[name!] in addition to name!()/name![]/name!{}

```

or the slightly simpler but harder to read:

```rust
macro_rules! my_attrib {
    () => ( #[cfg(foo)] #[derive(Clone)] )
}
my_attrib![] struct A;
// no change to today's macro syntax, only in where macros can be placed

```

Another, possibly more elegant solution, would be to allow macros like `#[my_attrib!] tt;` which are equivalent to `my_attrib!(tt);` (i.e. it takes the immediately following token tree and transforms it into another token tree). Perhaps it’s too general (just “another way” to do the thing in the first example), but it seems nice and it enables a slightly nicer syntax (for the first example, and many other current uses of macros):

```rust
macro_rules! #[my_attrib] {
    ($i: item) => ( #[cfg(foo)] #[derive(Clone)] $i )
}
#[my_attrib!] struct A;

```

---

<div class="post-metadata">

**Author:** ![nrxus](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nrxus/32/3946_2.png) [@nrxus](https://internals.rust-lang.org/u/nrxus)\
**Post date:** [May 2, 2018, 8:16pm UTC](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404/22 "2018-05-02T20:16:57Z")

</div>

It’s true that `#![alias(foobar = cfg(...)]` already doesn’t work with the current attribute syntax, but it is not too far different from the current one.

#![alias cfg(…) = cfg(…)] is non-trivially different in my opinion and it feels strange since everywhere else we use `()` to capture a group. It could just be a gut reaction and I’ll definitely add it as an alternative when I post it as an RFC though.

---

<div class="post-metadata">

**Author:** ![nrxus](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nrxus/32/3946_2.png) [@nrxus](https://internals.rust-lang.org/u/nrxus)\
**Post date:** [May 2, 2018, 8:35pm UTC](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404/23 "2018-05-02T20:35:06Z")

</div>

@kennytmI think that when macros allowed in attributes, this in theory _could_ work but it feels like a hacky way of allowing attribute aliases.

I subscribe fairly heavily to the concept of making easy thing easy and hard things possible. Macros solve _hard_ problems which make them very useful but I find them to be unintuitive at first glance. I think the problem we are trying to solve is common enough, and “easy” enough that the solution should be easy at the moment of creation (making the alias) and at the moment of use (using the alias). I think that relying on attribute macros to solve this will fail on both ends.

When I compare these two pieces of code:

```rust
macro bar() {
  all(complicated, stuff, not(easy, to, remember))
}

#[cfg(bar!())]
mod foo

#[cfg(not(bar!()))]
mod baz

```

```rust
#![alias(bar = cfg(all(complicated, stuff, not(easy, to, remember)))]

#[cfg(bar)]
mod foo

#[cfg(not(bar))]
mod foo

```

I can’t help but feel like the second one is more intuitive and ergonomic. In the first example I have to both know and care that bar!() is a macro instead of simply using it as any other cfg attribute. When the alias is created, there is nothing in the alias that says this belongs in a cfg attribute, so it is non-obvious what the purpose of it is.

I think if the user needs something more complex out of their attribute alias, then their case is no longer the easy one and then they can make a macro for their use case once attribute macros are introduced in Rust.

@kaininoI agree that an attribute that is a combination of other attributes is ideal. However, I also think that if we allowed aliasing only cfg attributes at first, without putting us into a corner, we can start with a small feature that adds user-value in a non-breaking way. Please read my comment to @kennytm for my issue with solving this using macros.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:30am UTC](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404/24 "2019-03-25T08:30:07Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

[Previous page](https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404.md?page=1)