This comment raises a suggestion that seems workable to me, and that might make Rust’s module system easier to understand for people coming from other languages: allow /foobar/foobar.rs to be treated as /foobar/mod.rs. To avoid conflict, if /foobar/mod.rs exists, it would have to take precendence as the mod file, but if that file isn’t found we could fall back to /foobar/foobar.rs. This seems more similar to how many other languages work and I don’t see any way it would be incompatible or conflictual. Thoughts?
More broadly, Rust’s module system seems to be the cause of far more confusion than it deserves, given its limited inherent complexity, and figuring out ways it could behave more like how people expect seems like a good idea.
The current design is similar to other languages that I know. With Python, you either use foo.py, or foo/__init__.py. In Nodejs, you use foo.js or foo/index.js.
For your example, why wouldn’t you just write /foobar.rs instead of creating a folder?
I like that suggestion a lot. Alternatively, instead of requiring “/” to separate modules in paths, allow “.” to separate modules in paths. That is, instead of src/foo/mod.rs and src/foo/bar.rs, we should be able to use src/foo.rs and src/foo.bar.rs.
Note that for the same reason that the original poster cited, I usually don’t use lib.rs as the name of the main library module file. Instead, I usually use .rs. If I used lib.rs for everything then I’d have 10 lib.rs files open in my editor right now, with no easy way to quickly discern one from the other.
Probably because you want it to have submodules. An issue with mod.rs, which @briansmith alludes to, is that in many editor's interfaces emphasize file name without the directory path, so its hard to differentiate between your module files.
I'm not really sure if this is a good suggestion or not, but I think something should be done that would make Rust's modules easier for people to understand.
I’m not sure if this will make Rust’s module system easier to understand. It doesn’t address any of the inherent complexity of the system; it just bolts yet another rule on to it, thus making it more complex.
Also, who is going to expect this? I cannot think of any language I’ve used where the described convention was used. On the other hand, Python immediately jumps to mind as a language that does more or less the same thing Rust does.
Really, 90% of the problems seem to stem from people conflating mod and use. That’s not because Rust is bad, just that it’s different. I don’t know what more can be done, since it seems to be explained pretty thoroughly and carefully. At this point, I’m increasingly inclined to think people just aren’t reading the docs and are guessing at the semantics.
Finally, the editor thing is more a failing of the editor than of Rust. Not having a way to distinguish identically-named files in different directories seems like a design flaw. If it’s not something you can address on the editor side of things, you could always force a fix by using #[path].
I cannot think of any language I've used where the described convention was used.
seanmonstar gave two examples.
[edit: as sfackler noted, I got this backwards.]
Finally, the editor thing is more a failing of the editor than of Rust.
This "let them eat cake" attitude is fundamentally wrongheaded. Whether editors should be able to squeeze full filenames onto little tabs and not doing so is "a design flaw" is irrelevant ... people should not have to redesign the editors they use in order to use Rust effectively.
But this is not an issue of Rust alone. Many programming environments favour repeated naming in a directory structure over different file names for every component. For good reasons, I might add.
So it is an editor issue, in and outside of Rust. Just as Rust shouldn't force your editor, command-T also shouldn't force Rust.
Most of the time when I have modules that deserve a directory of their own and thus use the name mod.rs, I use the mod.rs file only to define other files (modules) and re-export. The mod.rs file is therefore very short and doesn't change a lot.
Example of a typical mod.rs file from a project of mine.
pub mod mdbook;
pub mod bookitem;
pub mod bookconfig;
pub use self::bookitem::{BookItem, BookItems};
pub use self::bookconfig::BookConfig;
pub use self::mdbook::MDBook;
So the mod.rs file doesn't need to be opened a lot unless you add or refactor modules. This mitigates the editor problem.
If it’s not something you can address on the editor side of things, you could always force a fix by using