Change #[lang="foo"]-style items to #[lang("foo")]

[pcwalton]

Only one ("string") literal allowed.

[lilyball]

Is this just to simplify the syntax for attributes? Personally, I like seeing #[crate_id="foo"] because it looks like I'm assigning "foo" to crate_id, and that's what I'm trying to do. #[crate_id("foo")] looks like I'm trying to invoke some functionality named crate_id with the value "foo".

[pcwalton]

It also lets us remove the brackets. #crate_id="foo" looks weird, but #crate_id("foo") doesn't.

[lilyball]

I like the brackets!

Removing the brackets means giving up the potential future use of # as an operator outside of attributes. Has this been considered? The meeting discussion seems to take it as given that removing brackets is a good thing. I also note that 3 months ago I commented about this same issue, and got no response there either.

Also, regarding the one literal restriction, doesn't that cause problems for deriving? #[deriving(Eq, Clone)] is pretty common right now.

[pnkfelix]

@kballard the word "literal" in "one literal restriction" is referring solely to string literals. All existing attribute syntax that doesn't use key="value string" would continue to work, I believe.

[lilyball]

Sorry, misclick.

[brson]

I'd rather use #[lang(foo)] since lang item names can just be identifiers.

[brson]

@kballard The problem with brackets is that we also want to add the bang to inner attributes, which means the syntax for inner attributes is #![foo];, which is a heck of a lot of syntax.

[lilyball]

@brson Why not drop the semicolon in that case? #![foo] seems reasonable.

And I agree that #[lang(foo)] is appropriate for that attribute. But attributes like crate_id, crate_type, license, etc. make more sense using the #[crate_id="foo"] syntax.

[brson]

@kballard @pnkfelix likes the semicolon. This is a discussion for #2569.

[brson]

Maybe we should have a discussion on the mailing list about the complete plan for attributes before going through with this.

Personally, I also like the brackets.

[brson]

If we just leave attribute syntax alone it will prevent a lot of work, at the expensive of people forever wtfing over the semicolon distinction.

[glaebhoerl]

Ever since the idea came up I've been writing attributes as #attr and then having to correct myself to add the brackets.

[pnkfelix]

Accepted for 1.0, P-backcompat-lang.

[brson]

I think I've made my peace with foo("bar") as a replacement for foo = "bar", independent of whether we remove brackets. There's something appealing about just using s-expressions for attributes if we can.

[fhahn]

Is there a consensus for this issue?

Should it be foo("bar") ? I think this would require changes to the attribute parsing, because the item expected between the () seems to be an ident.

I've created a quick proof of concept patch that uses lang(foo) but I did not convert the existing lang items yet.

[brson]

@fhahn Yes, let's do it. It does require changes to the parser.

[fhahn]

Okay, so the parser should be extended to accept strings in items, like lang("foo")?

I'll be away for a week or so, so I'll probably won't get much work done next week.

[brson]

@fhahn yes.

[alexcrichton]

Nominating for closure. I think with #12538 we don't need to change this

[pnkfelix]

closing; there are some proponents for doing this but the presented arguments are not really strong enough to continue discussing it. (e.g. some arguments involve coupling in other changes to the attribute syntax, such as switching to @ for attributes)

[glaebhoerl]

Are there any compelling arguments for having the brackets other than historical inertia?