Summary

Change cfg_attr to allow

許可する、可能にする
multiple
複数の
 attributes after the configuration predicate, instead of just one. When the configuration predicate is true, replace the attribute with all following
下記の、次に続く、追従する
 attributes.

Motivation

Simply put, ergonomics and intent. When you have multiple

複数の
attributes you configure away behind the same predicate today, you need to duplicate the entire predicate. And then when you read code that does this, you have to check the entire predicates with each other to make sure they're the same. By allowing
許可する、可能にする
 multiple
複数の
 attributes it removes that duplication and shows explicitly
明示的に
 that the author wanted those attributes configured behind the same predicate.

Guide-level explanation

The cfg_attr attribute takes

とる
a configuration predicate and then a list
リスト、列挙する
 of attributes that will be in effect when the predicate is true.

For an example of multiple

複数の
attributes, say we want to have two attribute macros (sparkles and crackles), but only when feature = "magic" is enabled. We can write this as:


#![allow(unused)]
fn main() {
#[cfg_attr(feature = "magic", sparkles, crackles)]
fn bewitched() {}
}

When the feature flag is enabled, it expands to:

#[sparkles]
#[crackles]
fn bewitche() {}

The list

リスト、列挙する
of attributes may be empty,
空の
 but will warn if the actual
実際の
 source
元の
 code contains
含む
 an empty
空の
 list.
リスト、列挙する

Reference-level explanation

The next section

節
replaces what's in the Conditional
条件付き、条件的
 Compilation Chapter for the cfg_attr attribute. It explains both current and new behavior,
ふるまい
 mainly because the current reference
参照
 material needs improvement.

cfg_attr Attribute

The cfg_attr attribute conditionally includes attributes based

基となる、基底(の)
on a configuration predicate.

It is written as cfg_attr followed

下記の、次に続く、追従する
by (, a comma separated
分割する
 metaitem sequence,
連なり、並び
 and then ) The metaitem sequence
連なり、並び
 contains
含む
 one or more metaitems. The first is a conditional
条件付き、条件的
 predicate. The rest are metaitems that are also attributes. Trailing commas after attributes are permitted.
許す
 The following
下記の、次に続く、追従する
 list
リスト、列挙する
 are all allowed:
許可する、可能にする

  • cfg_attr(predicate, attr)
  • cfg_attr(predicate, attr_1, attr_2)
  • cfg_attr(predicate, attr,)
  • cfg_attr(predicate, attr_1, attr_2,)
  • cfg_attr(predicate,)

Note: cfg_attr(predicate) is not allowed.

許可する、可能にする
That comma is semantically
意味論的に
 distinct
区別された/独立した
 from the commas following
下記の、次に続く、追従する
 attributes, so we require it.

When the configuration predicate is true, this attribute expands out to be an attribute for each attribute metaitem. For example, the following

下記の、次に続く、追従する
module will either be found at linux.rs or windows.rs based
基となる、基底(の)
 on the target.

#[cfg_attr(linux, path = "linux.rs")]
#[cfg_attr(windows, path = "windows.rs")]
mod os;

For an example of multiple

複数の
attributes, say we want to have two attribute macros, but only when feature = "magic" is enabled. We can write this as:


#![allow(unused)]
fn main() {
#[cfg_attr(feature = "magic", sparkles, crackles)]
fn bewitched() {}
}

When the feature flag is enabled, the attribute expands to:

#[sparkles]
#[crackles]
fn bewitche() {}

Note: The cfg_attr can expand to another cfg_attr. For example, #[cfg_attr(linux, cfg_attr(feature = "multithreaded", some_other_attribute)) is valid.

有効な、正しい
This example would be equivalent
等価
 to #[cfg_attr(all(linux, feaure ="multithreaded"), some_other_attribute)].

Warning When Zero Attributes

This RFC allows

許可する、可能にする
#[cfg_attr(predicate,)]. This is so that macros can generate it. Having it in the source
元の
 text emits an unused_attributes warning.

Attribute Syntax
文法
 Opportunity Cost

This would be the first place attributes would be allowed

許可する、可能にする
in a comma-separated list.
リスト、列挙する
 As such, it adds a restriction
制限
 that attributes cannot have a non-delimited comma.

Today, an attribute can look like:

  • name,
  • name(`TokenStream`)
  • name = `TokenTree`

where TokenStream is a sequence

連なり、並び
of tokens
トークン
 that only has the restriction
制限
 that delimiters match
一致する、マッチさせる
 and TokenTree is a single
単一の
 identifer, literal, punctuation
句読点
 mark, or a delimited TokenStream.

With this RFC accepted,

受け付ける、受理する
the following
下記の、次に続く、追従する
 cannot ever be parsed
構文解析する
 as attributes:

  • name, option
  • name = some, options

Arguably, we could allow

許可する、可能にする
(name, option), but we shouldn't.

This restriction

制限
is also useful if we want to put multiple
複数の
 attributes in a single
単一の
 #[] container, which has been suggested, but this RFC will not tackle.

Drawbacks

It's another thing that has to be learned. Though even there, it's just learning that the attribute takes

とる
1+, and not just 1 attribute.

It restricts

制限する
the future allowable syntaxes
文法
 for attributes.

Rationale and alternatives
代わりのもの、選択肢

We could require that multiple

複数の
attributes must be within in a delimiter to make it so that it's always two arguments
引数
 at the top level. E.g., #[cfg_attr(predicate, [attr, attr])]. While this could increase clarity, it mostly seems like it would just add noise. In the multiline case, it already reads pretty clear with the predicate on the first line and each attribute indented.

The default alternative

代わりのもの、選択肢
of not doing this is a possibility. It would just mean that conditionally including attributes is slightly less ergonomic than it could be.

We could change attribute container syntax

文法
to allow
許可する、可能にする
 multiple
複数の
 attributes and then state that cfg_attr takes
とる
 the attribute container syntax
文法
 without the #[] part. While this could be a good final state, it's a more ambitious change that has more drawbacks. There are legitimate reasons we'd want cfg_attr to take
とる
 multiple
複数の
 attributes but not the attribute container. As such, I would like to go with the conservative change first.

The original draft of this RFC only allowed

許可する、可能にする
one or more attributes and did not allow
許可する、可能にする
 the trailing comma. Because it helps macros and fits the rest of the language,
言語
 it now allows
許可する、可能にする
 those.

Prior art

I cannot think of any prior art specifically,

特に
but changing something from taking
とる
 one of something to one or more of something is pretty common.

Unresolved questions

None.