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.

1 Like

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.