Rust 2018: an early preview


#61

I like the changes to macros in module system, as someone already wrote above this will syntax will be pretty, (both foo and bar extern crates)

use foo::foo!;
use bar::{bar!, zoo!};

One thing may be inconsistent (in my opinion) is that for submodules we still need to use #[macro_use], it will be better to extents syntax for external crates for submodules.

In our crate, we have a zoo submodule with #[macro_export], the above syntax is consistent.

use zoo::{zoo!, copy!};

This even leads to re-exports for libs, being able to re-export their macros in a simplified prelude.

pub mod prelude {
    pub use macros::{scr!, link!};
    /* ... */
}

#62

I like most stuff, but I’m not a fan of the anti-pub lint in binary programs. It sounds nicer to me to make my structs “public”, even if public is restricted to the local crate in this case. I always thought of crate as something that is used only in libraries when pub means super public, and something that wouldn’t be used that much. But now it seems like crate has completely replaced pub in binary programs and I’m not a fan of that. It’s longer, and if I ever want to separate stuff into a library then that’s going to be more difficult, renaming all the crates to pub.


#63

Maybe pub can be made to mean pub(crate) and pub(api) (or pub(extern)) to mean pub?

The more public an item is, the longer access specifier it should have.


#64

I make stuff pub in binaries sometimes so I can generate docs for them, for my own use.


#65

Slightly off-topic in here, but if it’s for your own use, you can pass --document-private-items to rustdoc.


#66

Actually, what I tend to do these days is put whatever the logic of my command line app is in a library (lib.rs), and then add a (bin/cmd.rs) with just the args parsing, logger setup etc.