Change inner attribute syntax for clarity and consistency

[brson]

As discussed in #2568, the trailing semicolon to differentiate 'inner' from 'outer' attributes is not intuitive. Also, #2498 will add doc comments as a special form of attribute, which will differentiate 'inner' doc comments using doxygen's /**< */ syntax. To make inner attribute syntax more consistent with doc comments and more visually distinct I would like to change the inner attribute syntax to:

#<attribute>

The meaning would still be the same - it's an inner attribute - but in practice you would probably think of them as 'crate attributes' or 'module attributes' since they typically would appear at the top of files and apply to whatever the file represents.

No attribute is followed by a semicolon.

---

Added clarification for people visiting this bug in the future (e.g. for triage), mostly to explain the "inner" vs "outer" distinction, because that terminology is not used in the Rust manual: Currently attributes in Rust can either be terminated by a semi-colon, or they can leave out the semi-colon; the former denotes an "inner attribute", which applies to the (entire) entity that the attribute is declared within, and the latter denotes an "outer attribute", which must be followed by an entity (and applies solely to that entity).

This bug is discussing a number of alternatives to that syntax. Lets see if we can enumerate the proposals and how much interest they have garnered. (Most of the proposals keep the existing outer attribute syntax unchanged, but there is one exception, so I include it in my examples below.)

1. (current) semi-colon inner: mod foo { #[outer(attr)] mod bar { #[inner(attr)]; } }
2. brson's orginal angle-bracketed inner: mod foo { #[outer(attr)] mod bar { #<inner(attr)> } }
3. bstrie leading exclamation inner: mod foo { #[outer(attr)] mod bar { #![inner(attr)] } }
4. graydon nested exclamation inner: mod foo { #[outer(attr)] mod bar { #[!inner(attr)] } }
5. brson bracket-less for both, leading exclamation inner: mod foo { #outer(attr) mod bar { #! inner(attr) } }
6. bstrie bracketed-inner, bracket-less outer: mod foo { #outer(attr) mod bar { #[inner(attr)] } }
7. pnkfelix semi-colon terminated bracket-less inner, bracketed outer: mod foo { #[outer(attr)] mod bar { #inner(attr); } }

Note also of course that we have indeed now switched to denoting macros with a trailing ! as discussed in the comments, which paves the way for the bracket-less forms.

[brson]

This should make attribute parsing significantly simpler since there's a fixed amount of lookahead needed to know if you are parsing an inner attribute.

[graydon]

I'm ok with this but as mentioned in the other bug on doc comments, think angle-bracket might not be the most delicious choice. It's not really visually suggestive of what it applies to; the semi rule had that going for it (with the drawback being, I guess, both subtlety and no obvious connection to any doc-comment syntax).

Maybe something involving exclamation points or vertical bars? :)

[graydon]

(only half joking; we adopted shebang comments already and intend to have those around for tagging language-version. maybe you can dangle this function on a relative of that syntax)

[Dretch]

I guess it has much the same issues, but how about ^ instead of < ?

[brson]

@Dretch. I think ^ looks ok in comments but don't see a nice way to wedge it into the attribute syntax - #^[attribute], #^attribute^.

[bstrie]

I'm surprised that graydon suggested the shebang notation, because I was going to suggest

#![module_level_attribute]
// as opposed to
#[function_level_attribute]

...but I thought people would think it was too silly. :) I still like it, though!

[graydon]

Yeah. I've poked at this long enough in my own emacs buffer now to feel positive about the bang-mark. It goes ok in comments too. Though to ensure we don't confuse any shell interpreters trying to run attributes, I think it should differ in first-two chars from shebang itself. I.e. move the bang inside the attribute. So we wind up with:

// shebang means 'run through this interpreter', like always
#!/bin/env rustc --run 

// leading sharp-comments in the root source file are scanned for pre-parsing control tags.
# rust: <compiler-uuid> <low-lang-version> <high-lang-version>

// bang-attrs apply to their containing item.
// in practice so far these seem to be module-level
// most of the time, so are "evocative" of shebang and
// pre-parse control tags, without being ambiguous with them
#[!warn(no_implicit_copies)]

// normal-attrs apply to the following item.
#[test]
fn test_patience() { ... }

// bang-comments are docstrings that apply to their enclosing item.

//! this is a one-liner.
/*! This is a
 *  multi-line one.
 */

// Common triple-slash and double-star doc-comments
// apply to the next item.

/// Magic number
const x = 10;

/** Very enjoyable
 *  function doc
 */
fn joy() {
}

Is this too ghastly? It looks ... ok to me. I mean, it's a stretch but we have a bunch of layers of functionality to get to hang together here and it'd be good to have it "work" nice.

(In theory we could also wedge-in a pre-parse conditional-compilation mode, via the plain-sharp coments, as an escape hatch for conditionally-compiling things that differ at only a lexeme-by-lexeme level. Sometimes the resolution of the #[cfg(...)] attribute is just not fine enough. Might be nice?)

[brson]

The bang does look good. The main reason I didn't want to use it is because in doxygen /*! and /** mean the same thing, but it is the best looking alternative.

We should change the attribute grammer to only have one meta item per. This is something I've wanted to do anyway as a simplification, but I really don't want to be able to write #[!inner, outer]. Maybe #![inner] is less confusing.

The bang does strongly suggest logical negation though. What does #[!cfg(unix)] mean?

One thing that might impact attribute syntax is that pcwalton wants to change the extension grammer to be fmt! instead of #fmt, which I like. This would open more possibilities in the attribute grammer. Specifically, we can get rid of the brackets:

# cfg(unix)
fn foo() {
    #! cfg(unix)
}

Of course then you have to worry about distinguishing between attributes and a shebang.

[bstrie]

I'm not sure that we need to resort to #[!. I'm having a hard time imagining any situation where the token #![ could begin a legal shebang (so it would always just throw an error), and since the only time this would ever be encountered would be if someone tried to ./their_rust_program, and since they'd need a valid shebang in that case regardless (and since shebangs can only occur on the first line of a file), I don't know if this could ever be an issue. Worse still, #[! would seem to collide with negation within attributes; does #[!cfg(target_os = "win32")] mean "don't do this on windows"?

Iff you are swayed by these arguments, I think a clearer rule for the docstrings and attributes would be "docstrings and attributes apply to the following item, unless their opening token is followed by a !". So you'd have:

#!/bin/env rustc --run
// for the set of people who like to run their programs directly,
// and thus will not be at all confused as to what a shebang is

#![module_level_attribute]
///! module-level one-line doc comment
/**! module-level
 *   multiline doc comment
 */

(New personal resolution: submit one unrelated-to-syntax patch for every bikeshedding comment I make.)

[bstrie]

re: brson's comment (which wasn't here when I started typing the above): I really adore the bracketless notation, and also signifying macros with a trailing !. Once again, I don't think it would be at all hard to disambiguate with shebangs, since people who want to use shebangs will know what a shebang is, and since you can't stick / inside a valid rust identifier (and since shebangs must contain absolute rather than relative paths), and since (on bash at least) shebangs can only appear in the very first line of a file, so it's easy to test for.

(patch_debt++)

[z0w0]

I just got assigned this for the triage. I actually feel that the current syntax is more consistent than the suggested alternatives. Does anyone have strong feelings about this still?

[bstrie]

@z0w0 I still have strong feelings that the existing trailing-semicolon-inner-attribute syntax is very bad, I just think there's been no real discussion of what to replace it with. Would be nice to bring this up on the mailing list and fish for comments.