I like this! I especially appreciate the details under the “knobs” sections.
Determining module structure from the file system is fine with me, even making modules themselves
pub(crate). The visibility of modules themselves doesn’t seem to add much, and this neatly sidesteps the issue of specifying it without
mod declarations. (I had suggested keeping
pub mod declarations to specify visibility in the last thread but this feels nicer.)
I will admit the
git stash scenario could become an issue. Along the same lines, it may make external build system integration harder- one of the pitfalls of
Makefiles that determine which files to include automatically is that \a file deletion doesn’t trigger a rebuild- explicitly listing source files in some way fixes that.
I’m also relatively positive on
import. I like that it keeps the same ordering while making it obvious that something is from another crate. It also solves the difference between the root module and submodules by removing crates from the root scope. (For reference, re @nikomatsakis’s coment, I always tend to go straight for
use std::cmp; rather than trying to write
I am still not happy about relative paths in
use statements, though. I use a lot of absolute paths to refer to things in the same crate. Perhaps I’m weird- this should be possible to collect some data on? I also suspect that the confusion about differences in
Perhaps it would be helpful to go in the other direction? Without
mod declarations, submodules don’t need to be in scope just by existing. So maybe we should change everything to absolute paths, modulo any
use statements. This seems to have precedent in other languages as well.
I am also still concerned about backwards compatibility. I’d prefer a bit more caution before doing anything that would require a new checkpoint. The more we can make work on current Rust the easier the transition will be if we need one.