RFC for attributes on statements and blocks.

[huonw]

Allow attributes on more places inside functions, such as statements and blocks.

[sfackler]

Missing attribute?

[huonw]

This is meant to be a bad example:

i.e. the following is invalid:

[sfackler]

Ah, I misread

[emberian]

👍

[andrew-d]

👍 - this would be nice to have 😄

[esummers]

Looks unnatural to me if extended to if/else. My random thought is that maybe if/else should look more like a match:

if foo => { },
#[cfg(foo)] if bar > 10 => println!("Hello World."),
_ => println!("So Long, and Thanks for All the Fish.");

[huonw]

I've been thinking about it a little more, and I actually think my second proposed if/else extension (i.e. else #[attr] { ... } and else #[attr] if ...) is the most natural (other than completely changing the if syntax... which seems like a non-starter); it's natural because if/else look like

if ... {
     ...
} else X

where X can be a block { ... } or another if ... { ... chain, and these two things get attributes from this RFC already, so (theoretically) there won't even need to be a special case for parsing those attributes: they come automatically out of the new grammar.

[esummers]

I think that looks the best too. else is basically a four character wide comma.

[andrew-d]

So, what's the process to get a consensus on this? Having this merged would be super useful for me right now.

[alexcrichton]

@andrew-d, the process is outlined in RFC #1, the relevant part being:

Eventually, somebody on the core team will either accept the RFC by merging the pull request and assigning the RFC a number, at which point the RFC is 'active', or reject it by closing the pull request.

Discussions of RFCs are predominately occurring during weekly meetings right now, but this is not a hard requirement.

[nikomatsakis]

I'm generally in favor. I'm vaguely concerned about parser ambiguities but it should probably be ok. (Oh, my kingdom for a proper grammar.)

[chris-morgan]

@nikomatsakis I don't see any ambiguities: attributes and only attributes start with #. This is still LL(1).

[nikomatsakis]

@chris-morgan I generally agree, I've just learned to be cautious when it comes to annotations that precede blocks etc.

[flaper87]

I'm in favor 👍 🍰

[lilyball]

👍

[pnkfelix]

I don't think its explicitly spelled out in the RFC, so I will ask: Are only outer-attributes allowed to be used in this manner? Or are inner-attributes allowed as well?

Supporting inner-attributes could help improve the appearance of e.g. the if/else examples, depending on what one's opinion is of the examples that were presented.

So, If the intent is that inner-attributes should also be allowed, then we would need to resolve questions of what their scope is (I'm guessing it would be the most tightly enclosing block), and it would probably be good to require all inner-attributes to occur at the start of the block, before any items/declarations/outer-attributes etc).

But I would be fine if inner-attributes are not supported, or are not supported in the first iteration of this feature.

[brendanzab]

Could this include blocks?

#[attr] {
    // ...
}

{
    #![attr]
    // ...
}

[alexcrichton]

There was a good amount of discussion in today's meeting about this RFC.

The general opinion is that it seems a little odd to limit attributes to just statements. One big reason is that many things which look like statements are actually expressions, such as:

fn foo() {
    if some_condition() { println!("test") } // this is an expression, not a statement
}

There are some concerns about how far-reaching it would be to modify the grammar to allow attributes on all expressions (which is the ideal ending point for something like this).

In the meantime, how would you feel about paring down the RFC to just attributes on match arms? That seems have a very real and pressing use case, and it pretty much works as expected because it can appear anywhere a match can appear.

[huonw]

Should I cut it down here? Or open a new RFC, since it will be a rather large simplification (maybe this RFC can be co-opted for the more general statements/expressions attributes).

[alexcrichton]

I think either way is ok. It sounds like statements/expressions will want to be a separate RFC, so feel free to pick either one to be this one (whichever is easiest)

[huonw]

I opened #49 since pretty much none of the discussion here is about match arms. (I'll update this to be statement/expression specific at some point.)

[huonw]

Updated.

[anasazi]

+1 Attributes on all the things!

[emberian]

A possibly better way to implement this generically would be to add an
sidetable containing all NodeId => Vec, and then we don't need
to pollute the entire AST with 4 words everywhere for the attributes it can
have. This does mean giving more things Ids I think. Possibly not.

On Tue, Jun 3, 2014 at 2:09 PM, Eric Reed notifications@github.com wrote:

+1 Attributes on all the things!

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

http://octayn.net/

[pnkfelix]

Some notes from discussion during triage meeting:

1. The scope of the RFC needs to be precisely defined. The detailed description section includes a fuzzy optional extension to expressions. Trim it to exactly what we'll support.
2. There are some questions that need to be resolved.
   • From one POV it seem safe to restrict the scope of the rfc to just blocks and statements, but every expression can be turned into a statement, so its not clear whether that actually restricts the scope of the RFC all that much.
   • Also it would be good to know whether inner attributes are including the scope of this RFC, and if so, what do they apply to (just blocks, presumably?)

@nikomatsakis you had some additional thoughts that seemed a little implementation oriented in terms of what it would be like to parse code that has an arbitrary number of attributes followed by some statment-or-expression, feel free to to to clarify my points above.

Anyway, @huonw , we invite you to revise the RFC and then we will try to address it formally at a team meeting.

[sfackler]

As a point of reference, Java 8 significantly expanded the parts of the grammar that can be tagged with annotations: http://java.dzone.com/articles/java-8-type-annotations

[huonw]

Updated to include expressions more definitely. There are some annoying interactions with if detailed in the last section.

[glaebhoerl]

Markdown is interpreting this as a heading :-)

[huonw]

Haha, whoops. Fixed.

[tbu-]

Not related to attributes in general, but allowing #[cfg]s everywhere makes it harder to reason about the code, like in C/C++ when you have preprocessor logic all over a function instead of different functions where the platform specific behavior is isolated.

That's why I think it might be a bit dangerous to allow this as this might make people move away from separate functions for #[cfg]-dependant behavior.

[pnkfelix]

@huonw oops, missed this earlier: I assume you wanted to finish this sentence with a period, or some expository text explaining why narrowing the scope of the change could be good, or more importantly, why it is not good, i.e. reiterating why it is important to support annotating (most) expressions.

[brson]

Discussed https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-07-15.md. Accepted.

[slimsag]

shouldn't this be removed from the active RFC list if it's been accepted/merged?

[sfackler]

The active list contains RFCs that have been accepted but not implemented.

[Kimundi]

I'm currently in the process of implementing this, and in accordance with the current RFC text attributes will be initially prohibited on if expressions.

However, thinking about it I wonder if the following scheme could be used:

#[covers_remaining_three] if expr #[covers_block] {
    // ...
} else #[covers_remaining_two] if expr #[covers_block] {
    // ...
} else #[covers_block] {
    // ...
}

The idea being that an attribute before an if token applies to the whole, chained if expression, while a attribute before the block only applies to that block expression.

Of course, the "disadvantage" here is that for consistency you'd want to support those block-only attributes on anything taking a block, like the loop expressions. And then there would be more than one location per block-taking expression where a attribute might apply, which while not ambiguous could become potentially confusing.

[huonw]

@Kimundi, that is in fact one of the alternatives. I think nailing down this aspect of the behaviour is probably worth an amendment RFC.