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

[cmr]

Maybe, but I don't think it's a big concern.

[pnkfelix]

If we go down this road, I assume there would be a distinction between:

#[attr] if foo { ... } else { ... } // applies to whole statement, including both branches

and

if foo #[attr] { ... } else { ... } // only applies to the then-branch

I don't have a problem with this; if you cfg-disable a then-branch, you get a compilation error, presumably. (Though I do think it might motivate support for inner attributes.)

[cmr]

I think this is an important detail. As I see it, #[attr] if ..., the attribute would apply to the expression, but if foo { #![attr] ... } would have it apply to the block. I do not want to allow if foo #[attr] { ... }, I find it confusing.

[pnkfelix]

I'm not inclined to disallow if foo #[attr] { ... } though I also would probably find inner-attributes more readable.

(I'd suggest we "just lint for it", but ... Does our lint infrastructure have enough info to try to catch the outer-attribute form here? Or are all the attributes boiled away by the time the lints run?)

[huonw]

I was thinking that if ... { ... } was a single unit, i.e. the {} are part of the if not a separate block. Maybe having both separately would be OK (I hadn't thought about it at all).

[lilyball]

@huonw I have the same feeling. if expr { ... } feels like a single unit to me. If #[attr] were allowed on just the { ... } then I would expect if expr expr to be valid (e.g. if true println!("this works?");. But it's not valid.

Given that, I also find the suggestion of if expr { ... } else #[attr] if expr { ... } to be invalid. An else-statement is also a syntactical construct where the body is either an if-statement or a braced block. And if you really think this should be valid, then I question what happens if the #[cfg(foo)] evaluates to false? You then have a bare else with no associated code. I think that if you want an attribute on an else-if then you just need to nest, as in if expr { ... } else { #[attr] if expr { ... } }. Usage of this should be rare enough that this nesting is not a problem.

[lilyball]

Oh, and given all that I said above, I think the inner-attribute form doesn't make sense, as it appears as though it should affect the block, not the entire if-statement (especially if it occurs inside of an else-block). Similarly, putting the attribute in between the expression and the block makes no sense.

Disallowing these usages also resolves the question of how to deal with needing to select between several behaviors. if expr #[cfg(one)] { ... } #[cfg(two)] { ... } #[cfg(three)] { ... } looks pretty nonsensical, especially if two of the configs match (or if none match).

Additionally, if we did allow #[attr] on just the block, that would imply that we should allow it on all expressions, not just statements. I can see why that might be desired, but in actual practice it seems like it would be extremely confusing. Restricting it to blocks instead of arbitrary expressions would lessen the confusion, but would reintroduce confusion over why you can't put an attribute on the block of an if-statement (and allowing that brings up the problems I already mentioned).

Overall, I think the simplest thing to do is to just allow it on match arms and on statements. Not on blocks or expressions (unless those happen to be statements as well).

[cmr]

👍

[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!

[cmr]

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.

[kmcallister]

This would be really useful, especially with lint plugins. I'm interested in implementing this if the RFC is accepted.

[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.