Path clarity project organization and


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/ and src/ (ignoring camel case etc conventions for now). But once the traits and their implementations and tests become too large src/ and src/ 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 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 for each module to tie the source files into each module?

Any advice much appreciated,



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/ or src/ regardless of whether A has submodules or not. Previously you’d have to rename src/ to src/A/ if you added src/A/

You can move tests to submodules. For example, add mod tests; in each module and put tests in src/A/ 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.


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

Thanks for the clear explanation too.