4 ms·
> http://rust-lang.github.io/book/ch07-00-modules.html http://rust-lang.github.io/book/ch07-00-modules.html is the second edition of the book's chapter on it, I
by mathw 10y ago
> http://rust-lang.github.io/book/ch07-00-modules.html http://rust-lang.github.io/book/ch07-00-modules.html is the second edition of the book's chapter on it, I think it's much better.
It is better, yes, although I think it takes a while getting to the point in a few places.
Docs are something I'm interested in, so you might hear more from me through appropriate channels about this and that.
> Yes, that is how it works. Macros aren't in a namespace. Yes, it's weird. It's an artifact of history; eventually, it will be fixed.
I'm glad that I both got it right and that it's not necessarily going to stay that way. I don't know how much macros are going to proliferate in the future, but I don't want to find myself with macro naming collisions. I can certainly imagine some of nom's causing issues with other crates, and having to define a new crate within my tree just to contain them would be irritating. I assume that would work as a workaround, anyway.
- steveklabnik 10y agoGreat. Please don't hesitate to reach out and or file issues or whatever, I really want to make this stuff good. Basically, today you define macros with macro_rules!. This shipped in Rust 1.0 because we did not have the ability to invent and implement a more proper macro system, and didn't want to hold the whole language up on one thing. In the future, you'll write macros with a "macro" keyword, and macro_rules! will be deprecated, and "macro" macros will support namespacing, etc.
- mathw 10y agoIs that "Macros 2.0", or something beyond that?