Make brackets optional for single attributes

[glaebhoerl]

This is an alternative to #483: instead of changing attributes to @, just make the brackets optional for #.

Note that I'm not opposed to #483, and am only presenting this as an alternative to consider, although I have a slight preference for it. From a practical perspective, it has the benefit of being backwards compatible.

Splicing in my comment from the other RFC:

I'd be fine with @ as well. It's a somewhat nicer symbol... precisely because it's a nicer symbol, however, it has a lot of possibility as potential syntax for future language features we haven't even thought of yet, whereas # is most likely too ugly to use for anything else. So keeping # for attributes would be a more efficient use of limited ASCII real estate.

CLICKME

[ftxqxd]

# isn’t ugly :’( For that reason I like it, wherever it’s used. To be honest I don’t really follow the argument given: using @ for attributes seems like the best use I can think of, even taking into account future improvements, as it’s so well suited for it (with precedent in other languages). It’s also for a pretty commonly used feature, so even if some amazing new use came along, I don’t think we’d regret using it for something as common as attributes instead.

I also don’t see the point in keeping the [] syntax (apart from backward-compatibility), which I regard as ugly. #foo #bar is quite a bit shorter than #[foo, bar] and is significantly less noisy, too. It seems to have a bit strange to have multiple ways of writing the same thing: to cite the Zen of Python, ‘there should be one—and preferably only one—obvious way to do it.’ #doc="does something" or #doc("does something") also seems fine to me.

That said, I do like # in general. I’m still not sure if I prefer it to @ or not, but I’m not sure it matters (to me anyway).

[netvl]

I also don't understand why everyone thinks that # is ugly.
+1 from me, I also think that brackets should be optional. And backwards compatibility is a big win too.

[glaebhoerl]

To be honest I don’t really follow the argument given: using @ for attributes seems like the best use I can think of, even taking into account future improvements, as it’s so well suited for it (with precedent in other languages). It’s also for a pretty commonly used feature, so even if some amazing new use came along, I don’t think we’d regret using it for something as common as attributes instead.

I'm mostly thinking of Objective-C, which uses @ as a kind of catchall for every new piece of syntax sugar they want to add.

The main example I had in mind for Rust was some kind of generalized smart pointer sugar, where I have a hard time imagining that # would be considered appropriate. But there are probably others.

I also don’t see the point in keeping the [] syntax (apart from backward-compatibility)

That's the only reason. An earlier push to remove the brackets foundered on trying to remove the = form at the same time. As I wrote, there's no reason we couldn't make further changes in a followup RFC, if we wanted to. I just wanted to keep this one as minimal as possible to avoid running into those kinds of issues again.

[Kimundi]

Regardless of the the choice between @ and #, this seems like a improvement from the status quo that would work with either form without needing to make any other changes to resolve the ambiguity cases.

[bstrie]

Not so fast: Rust allows one to stick a hashbang in the first line of a file and have it Just Work as it does in shell scripts. Are we certain that this RFC would still allow us to parse that unambiguously?

If that issue is resolved, then I'd be fine with this (though if possible I'd rather go the extra mile and remove the brackets entirely, rather than merely let them be optional). It's not the # that's the ugly part of our current syntax, it's the [] that make my eyes bleed.

[Kimundi]

Hash bangs are not really an issue: They start with the same prefix as inner attributes, but we can just define the parser to ignore the first line if it has a leading #!. Maybe try to parse it and emit a warning if it could be a valid attribute, to make the programmer aware of the ignoring going on.

[UtherII]

On the drawback part, I'd state it make two differents syntax for the same thing.

[tomjakubowski]

Hash bangs are not really an issue: They start with the same prefix as inner attributes, but we can just define the parser to ignore the first line if it has a leading #!. Maybe try to parse it and emit a warning if it could be a valid attribute, to make the programmer aware of the ignoring going on.

Wouldn't this mean every crate root file using an inner attribute would need to start with a blank line or comment? Seems problematic.

[sfackler]

Why do we care about shabang support in rust files? Does anyone actually use it?

Actually, how would you even use it? #!/usr/bin/rustc will just compile the file, but not run it.

[reem]

@sfackler Eventually we main gain a rustci, so #!/usr/local/bin/rustci might actually be useful.

[reem]

We could just change the syntax for an outer attribute, maybe ## or !#.

[sfackler]

In any case, this RFC won't affect shebang disambiguation, since they're required to be absolute paths, and / is not a valid part of meta item syntax at that position.

[reem]

Oh, true. We could just check for #!/ and parse that as a shebang.

[liigo]

But inner attr #!foo can still be parsed as shebang which out of our
control.
2014年12月4日 下午12:15于 "Jonathan Reem" [email protected]写道：

Oh, true. We could just check for #!/ and parse that as a shebang.

—
Reply to this email directly or view it on GitHub
#484 (comment).

[sfackler]

Why couldn't #![foo]?

[nrc]

I believe we special case the first token in a file (maybe in a crate?)

[nrc]

We discussed this at the triage meeting. It generally looks like an improvement, but has the same ambiguity problems as #483 and is churn at this late stage. Thanks for writing the RFC!