I find bottersome that if a mod has a single submod, you are forced to create a folder for that single mod or inline the submod or use an include macro.
Currently you can put the mod source in one of the following:
I propose an alterntive location:
Is the #[path=] attribute suitable for you? That should support doing:
#[path = "submod.submod.rs"]
mod submod;
Thanks, didn't know that attribute, and assumed wrong. I still find it a prefered default path location.
There have been numerous discussions about naming files in Rust projects (one not too long ago too). I highly doubt there's appetite for changing things again after the 2018 Edition that got us the status quo. I'd encourage you to read about that before proposing "yet another naming scheme".
If you still find it compelling and worth the projects' investigation, the RFC template is a good guide for the kinds of information that is looked for and more-or-less asks for such historical research as a prerequisite. I'd recommend that path before raising it again; the same folks in those threads will undoubtedly show up in such a thread and it'd be good to address what has been stated before instead of rehashing all the old arguments again and again.
Because of backward compatibility, the existing file structure is here to stay. FWIW, I strongly think that this isn't a situation where adding a new option will simplify things, and as such, a new new option won't cut it.
Given a time machine, there are different decisions I might make. But what we have works and isn't worth adding further complications to.
I think if we do ever add a third way then the other ways should be deprecated and eventually removed over an edition. Having two ways to do the same thing (with neither so clearly better than the other) is not great. Having three would be much worse.
(That said, I wouldn’t be eager to see yet another way to do this even if it deprecated the others. Maybe if there was a very strong motivation for it to justify the churn and inevitable arguments).
Mandatory manual specification of the file path for all out-of-line modules.
mod foo = "whatever/you/want.rs";
It’s the only way to make everyone equally happy.
Note that this is likely closer to “unhappy” for “everyone”. But it is quite equitable!
It would take some getting used to, but I am quite serious when I say I think this would be an improvement to the language. The price is a minor amount of extra typing, and in exchange: a complicated set of rules that confuse beginners is completely eliminated; #[path] merges into the normal case; and all arguments about what the source file location of a module ought to be are rendered moot.
Ah, an optimist I see. I think it more likely it just moves the argument. There’s no longer an enforced standard so every project does their own thing and people would argue about which is more “correct”.
Sure someone would try to keep arguing over file organization, but it would no longer be IRLO's problem, and sensible project managers would say "This is how we organize the files in this project. We express no opinion on whether other projects should do the same" and leave it at that.
I think having arguments on IRLO is a small price to pay for having a module layout that’s (more or less) consistent across Rust projects. Once I’ve learned the two main ways of doing module imports I can go into almost any random Rust project and navigate around without having to learn what they consider sensible.
The IRLO arguments aren't really what I care about. What I care about is the complicated set of rules that confuse beginners. I recall we've had multiple people tell us this is a significant obstacle when you're starting out.
I don't see any way to make the rules simpler, without breaking existing code, that everyone will plausibly agree on, besides a transition to full manual (at an edition boundary, presumably).
Same way as for most other things, lints and warnings. I don’t think it’s reasonable for rust to start rejecting deprecated/soft deprecated module layouts, but gently nudging users towards one-ish generally good module layout bears similar benefits to everyone using rustfmt.
That's not actually solving the problem. It's abdicating responsibility for defining conventions.
Rust needs a[1] sensible default for file organization for exactly the same reason why it has the nonstandard_style warnings and comes OOTB with a package manager. All the value of this sort of convention comes from almost everybody using the same one, unless they have a particular reason not to. The lang team is the only group I know of with enough influence to actually make that happen: if they don't set a convention, I don't expect one would emerge spontaneously.
The only way one would emerge spontaneously would be for someone to come up with a way that's 10x better than most of the alternatives, and I don't think such a choice exists, because I think the confusion comes from mod statements existing at all. Because mod statements exist, the module hierarchy is not guaranteed to be a 1:1 match for the filesystem hierarchy, even though, most of the time, they are the same. Fixing this would require rustc to walk the directory tree, instead of hopping from file to file like it does now. And that is a much more radical change than any which has been proposed in this thread so far.
I am a little bit annoyed that Rust hasn't deprecated one of them. Seriously, just pick one and stick with it. Neither of them is unacceptably bad. Dealing with the existence of two options causes more harm than picking the less optimal one could possibly cause. ↩︎
I can confirm. Coming from C++, and being used with std::variant and functional constructions, the hardest thing in Rust for me was actually how do you #include another file!
I don’t think anyone would disagree that the current module situation is confusing to new users. But I also don’t think the solution should involve giving up and forcing projects to invent their own module layout.