Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAttributes: Redundant syntax, unnecessary complication #31001
Comments
This comment has been minimized.
This comment has been minimized.
|
The |
This comment has been minimized.
This comment has been minimized.
|
A similar suggestion has already been made here regarding doc-comments. To attach attributes to the local crate |
brson
added
the
rust-2-breakage-wishlist
label
Jan 20, 2016
This comment has been minimized.
This comment has been minimized.
|
These syntax forms are all stable, and while their design has drawbacks, we can't remove any of them. I believe the previous responses have answered your questions about why they are like they are. I did tag this as something to consider for Rust 2.0. |
brson
closed this
Jan 20, 2016
This comment has been minimized.
This comment has been minimized.
|
Thanks! Guess that makes sense. |
This comment has been minimized.
This comment has been minimized.
|
The real redundancy wrt attributes is that we allow both |
This comment has been minimized.
This comment has been minimized.
illustrious-you
commented
Jul 3, 2018
Now that |
prasannavl commentedJan 18, 2016
Well, I'm quite new to rust, so its entirely possible I'm missing something important. But I'm curious to know why the team chose to have two different type of
attributes, andcommentsas well.One is of the form
#[attr], while the other is#![attr].The former is straightforward, but the latter is for the item that its enclosing.
Taking the example right out of the docs
Is there a necessity for this redundant complication? I see no reason why the same
#[foo]can't be applied right outside the module.i.e,
Now, foo will apply into the scope. From what I can surmise, the only reason I can come up is, for scenarios like these:
But this can also be quite easily achieved with the compiler, this way,
Similar to how attributes are handled in C# for example. I see it from the perspective that a little more complication in the compiler to be able to resolve these would definitely be better than complicating the whole language by adding a language syntax that seems entirely redundant. And when it comes to readability, the one is actually quite better than a whole new syntax for achieving the same thing, because the intent is more consistent.
Same goes for comments, for the module as well. Can't this just be simplified? Rust already has a complicated enough learning curve, and these seem completely unnecessary. I'm hoping that I completely missed something, and I'm wrong :) .. or this is not the most stellar design choice that should be rectified as soon as possible while the rust ecosystem is still in its infancy.