Multiple Attributes in an Attribute Container

[Havvy]

Allow #[attr1, attr2] thingy.

Rendered

[petrochenkov]

Typo: "attriute"

[petrochenkov]

I'm wary of guaranteeing contents of input streams with such precision (at least right now).

For example, we don't specify what cfg_attr(predicate, a, b) unwraps into - #[a, b] or #[a] #[b], but now it makes observable difference (it would be reasonable to expect the former, but it's actually the latter).
Also, it may be convenient to split all multi-attribute containers into single-attribute containers in the initial implementation.

Macro authors should not rely on differences between #[a] #[b] and #[a, b] in general, and should support both, so we don't get much from specifying precise tokens.

[cramertj]

Macro authors should not rely on differences between #[a] #[b] and #[a, b]

When a macro author highlights the span of the attribute item containing e.g. #[a, b,] from #[a, b, c] where some c has been removed, what span does that point to? a, b without the #[] or the c? Similarly, does #[a] from #[a, b, c] refer to just the a? I'd really like to see the exact semantics of whatever attribute modification and span transformation we do specified, both for the sake of this RFC and for #2539.

[Centril]

What is the rationale for including the , here? Why not normalize the input before by having "#[attr1] thing" instead?

[Havvy]

No hard reason. I just figured that "remove the name, ignore preceding commas and whitespace" is an easy consistent thing to do. Nobody should really care that it looks like #[attr1, ] instead of #[attr1]. Is there a value in adding complexity by normalizing?

[cramertj]

After normalizing, what spans are provided to the procedural macro? It seems like they could wind up pointing to code that was different from what the user wrote originally, which could be confusing especially in cases where macros try to modify the users' code as an example for how to fix errors.

[Centril]

Elaborate on the question here?

[Havvy]

_Attribute_ in the reference is just InnerAttribute | OuterAttribute, but there's nowhere in the grammar that allows both, so it should probably just be removed from the grammar.

[nikomatsakis]

In a prior lang team meeting, @cramertj had a lot of concerns about the interaction of this with procedural macros -- e.g., if you have #[macro] #[foo, bar], does that get "normalized" in the input to macro etc? @petrochenkov wrote some similar concerns here.

It definitely seems like the RFC should specify clearly the interaction here. I'm also of the opinion that we should do some sort of normalization so that macros behave consistently without a lot of effort, but I don't know what the details ought to be. =)

[cramertj]

I have a number of concerns here around the precise semantics of how providing macros with a TokenStream that doesn't look exactly like the code provided the user will work, but those concerns mostly all apply just as well to #2539, so I won't file this as an official concern on the RFC, and I'll check my box in the case of an FCP.

[graydon]

Opposed, though not with vehemence, just a reasonable dose of conservatism. The drawbacks stated are clear enough:

The standard drawbacks to allowing more syntax exists. It's yet another thing to learn. It's only a small win over just having multiple attribute blocks

Those are reasons enough not to do this (as with so many of the open PRs here).

[Centril]

However, in this instance, cfg_attr(condition, attr1, attr2, ..) is already permitted so having #[attr1, attr2, ...] fits well with that.

[graydon]

"It has symmetry" is not a reason to do a thing. It adds more ways to do a thing nobody especially suffers from not having more ways to do.

[Centril]

Symmetry is however not the sole motivation:

It lets us express our intent more clearly when attributes added for the same reason are grouped together.

I think this is apt; for example: #[test, should_panic] #[allow(foobar)]] fn some_random_test() {...} -- the first two are related whereas the second not so much, grouping them offers more clarity IMO.

[graydon]

I'll admit this is a minor cost that is not going to break the bank, but like .. "indicating relatedness" can be accomplished today just by putting an extra newline between them, or putting the first two on a single line, or adding a comment, or putting things in a mod if the attr is shared across a bunch of items. Lots of ways to express group-y-ness, little reason to believe they're inadequate (and if they're not -- will it stop here? there are all sorts of things one might want to indicate relatedness-of in the language).

I'm only objecting here because this seems superfluous, like a part of a trend to reach for "add-or-change stuff in the language" where it's really not necessary. At this stage in a language's maturation, necessity should be the mother of invention, not plausibility.

[camden-smallwood-zz]

Was it necessary to add use/import grouping? No. There was still a gain from it despite introducing new synax to learn:

use std::ops::Add;
use std::ops::Sub;
// versus
use std::ops::{Add, Sub};

This is just as viable of an addition to the language as attribute grouping:

#[repr(C)]
#[derive(Clone, Copy)]
pub struct Point {
    pub x: i32,
    pub y: i32
}
// versus
#[repr(C), derive(Clone, Copy)]
pub struct Point {
    pub x: i32,
    pub y: i32
}

Could someone please explain why it would be a bad thing to support both of these paradigms? I don't get it.

[scottmcm]

Closing without prejudice as requested by the author.

Please feel free to re-open in future if you decide you'd like to come back to it.