[pcwalton]

For once, I'm gonna be the one sticking up for Go here. :) Pragmas or annotations are kind of unavoidable, and I don't think that it was a mistake to include them. I wouldn't have used comment syntax, but whatever; that's a minor quibble.

Actually, I wish Rust had done one thing that Go did: namespacing the pragmas. That would have been a more future-proof thing to do, because macros effectively give us user-definable pragmas, and once you have user-definable pragmas you have name collision problems. Kudos to the Go team for being forward-thinking there. I suspect we'll have to figure out some kind of solution here, but it won't be as pleasant as if we had just used namespaces in the first place.

[kibwen]

> Actually, I wish Rust had done one thing that Go did: namespacing the pragmas.

Yeah, of all the papercuts that the Rust 1.0 macros system had the idiosyncratic modularization/namespacing rules were the most unfortunate. Happily there's already an accepted RFC for the design of macro modularization (https://github.com/rust-lang/rfcs/blob/master/text/1561-macr...) that simply makes all macros operate under the same namespacing rules as all other items, and it looks to be mostly implemented as well (though it won't hit stable Rust until the larger macros 2.0 initiative is finished). And as for future-proofing, I'm not too concerned: all the "standard" macros can be exported from the stdlib prelude without a problem, and any libs that update to macros 2.0 can easily export the updated macros just like any other public item and consumers can update their code with only a single `use` declaration (it's not like the old macros system doesn't require explicit importing anyway, it's just unique and janky). Very much looking forward to the simplicity and consistency of the new system.

[ben0x539]

cool, I didn't realize this applied to attribute-style macro application too.

[Royalaid]

This does sound like a really good idea. Have you made an RFC or proposal to the team to see if it is possible?

[kibwen]

As I mention in a sibling comment, the RFC to make macros work with the module system like any other item has not only been accepted, but mostly implemented. :)

[brandonbloom]

You've missed the chance to include namespaces on the standard set, but is it too late to reserve un-namespaced annotations for official use?

[kibwen]

It's not too late. The Rust standard library has what's called the "prelude", which is a set of items (functions, types, traits) that are imported by default into every Rust program. So for example the complete Rust program `fn main() { let x = String::new(); }` works despite the fact that at no point did we import any type named `String`; this is because Rust programs implicitly link the stdlib by default, and the stdlib publicly exports the items in the prelude (https://github.com/rust-lang/rust/blob/master/src/libstd/pre...).

So in the future when macros are namespaced just like every other item (which is actually already designed and largely implemented, see my other comments here for links), all that needs happen is to export the newly-transitioned macros from the prelude and all will continue to work as usual. As for potential collisions with third-party macros, the old system already requires anyone who wants to import macros to stick a hacky "macro_use" pragma on their import statement, and old-style macros are specified to shadow rather than collide so there will be no need to be cautious with updating the stdlib. Third-party libs will be free to update to "macros 2.0" at their leisure (though the need to have users explicitly import macros will require those libraries to issue a breaking change when they do so), and old-style macros will be supported for quite a while though eventually they will be deprecated and discouraged (and presumably removed in some future epoch).