I also prefer the organization where mod.rs is placed inside the module folder. However, most editors sort files based on their names, which means mod.rs won’t be the first file! It will be mixed in with a bunch of other mod files! As a fellow Aquarius with a bit of OCD, this can be quite uncomfortable!
Personally, I’d love for mod.rs to be renamed to _mod.rs. That way, it would definitely be sorted to the top of the list (since the ASCII code for _ comes before lowercase letters). If _mod.rs looks too much like a "hidden" file, maybe we could go with $mod.rs instead?
Only if your editor sorts the filenames based on plain character code comparison. If it uses the locale-specified collation it is likely to put _file right next to file.
I'm sympathetic to basically all points raised in this thread (except maybe the git rename issue, since for me I keep mod.rs very minimal, so the interesting functionality goes into a submodule anyway). I consistently use the mod.rs structure.
For me, the low hanging fruit improvement would be to allow other standard names for mod.rs. For example, foo/mod.rs -> foo/mod_foo.rs.
This is the older naming convention that Rust also understands that we mentioned in the “Alternate File Paths” section of Chapter 7. Naming the file this way tells Rust not to treat the common module as an integration test file.
There's a semantic difference when using tests/common/mod.rs instead of tests/common.rs, just to complicate things even further!
Although to be fair, the practice of doing mod common; from multiple integration test files has its own issues; it ends up accidentally promoting mounting a module multiple times instead of useing it. Also, tests/foo.rs looks in /tests/ for a mod (like a crate root lib.rs, since that's what it is) instead of /tests/foo/ (like /src/foo.rs would).
If you have an involved testing harness, it can be a significant improvement to turn off automatic test discovery and use mod statements to mount all your integration tests into a single crate.
