Path clarity project organization and mod.rs?


#1

Suppose I have a library crate with two top-level modules “A” and “B”. Each of those modules has several traits I’d like to make available outside the crate, i.e., A::Trait1, A::Trait2, B::Trait1, B::Trait2.

I could shove everything for module A and B into src/A.rs and src/B.rs (ignoring camel case etc conventions for now). But once the traits and their implementations and tests become too large src/A.rs and src/B.rs become unwieldy.

Assuming a 2018 uniform paths (i.e. nightly) environment what’s the idiomatic way to split these files up? I understand I no longer need mod.rs files in each module directory and I’d like to keep the traits in the A:: and B:: modules if possible, rather than in their own submodules of A and B.

I think I would still need a mod.rs for each module to tie the source files into each module?

Any advice much appreciated,

Stu


#2

Nothing has changed in the logical organization of modules. You can still have modules A and B, you can still have them in separate files, and you can still add submodules to them. The thing that has changed that you can use src/A/mod.rs or src/A.rs regardless of whether A has submodules or not. Previously you’d have to rename src/A.rs to src/A/mod.rs if you added src/A/some_submodule.rs.

You can move tests to submodules. For example, add mod tests; in each module and put tests in src/A/tests.rs. Submodules can use items from their parent modules.

Keep in mind that thanks to pub use you can have your crate’s layout presented to users differently than your internal organization.


#3

In practice, I wonder if it will become idiomatic for larger multi-module projects to have both a src/foo.rs file and a src/foo directory containing, for example, src/foo/submod_1.rs. They could use src/foo.rs to declare foo submodules and to present a “shallower” foo layout via pub use statements.

Thanks for the clear explanation too.

Stu