3 ms·
Mine too, or rather, for my first rust project I initially had all the code in main.rs and then I found it very difficult to split up the project into several s
by nickez 10y ago
Mine too, or rather, for my first rust project I initially had all the code in main.rs and then I found it very difficult to split up the project into several source files. I think with some better documentation it wouldn't have been that hard.
- mathw 10y agoI think it's the documentation. It took me a few tries to get everything I needed out of the Book to use my own modules, but then it was easy. Although I still don't quite get how macro importing works. It feels like when you #[macro_use] on an extern crate you get all the macros implicitly everywhere without having to issue any use statements. This seems weird and I have yet to try to find an explanation of it. But I've got modules all over my Advent of Code solutions which use macros from nom without having any nom-related use statements.
- steveklabnik 10y agoYeah, I hear you. I've always thought this, and honestly, I think the issue is that I've always found the module system _very_ intuitive, so it's been harder for me to connect with how people struggle to learn it. 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. > This seems weird 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.
- Manishearth 10y agoSo here are some things the book chapter misses that are source of confusion elsewhere in this thread - `extern crate` is logically a crate-internal magic `pub mod` or `pub use` - You should usually put your `extern crate`s in the crate root - Putting these two together, you can refer to crates as if they were toplevel modules. This is one of the very common confusions I've seen.
- steveklabnik 10y agoMind opening an issue with this in it? <3
- Manishearth 10y agoDone, https://github.com/rust-lang/book/issues/397 https://github.com/rust-lang/book/issues/397
- 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?