A module groups related items—such as functions, structs, enums, and types—inside a crate. Instead of keeping every function in one namespace, you can separate code by purpose. For example, a greeting program can put name-reading functions in `input` and greeting functions in `output`. section 5.1 section 5.1.1
Declare a module inline with `mod input { ... }`, or put its contents in `input.rs` and declare it with `mod input;`. A separate file makes a larger module easier to find, but gives it the same isolation as an inline module. Rust needs the `mod` declaration to find the file; the file’s presence alone does not add it to the crate. section 5.1.2
Listing 5.5 Greeter program main.rs
use input::get_name;
use output::{goodbye, hello};
mod input; #1
mod output;
fn main() {
let name = get_name();
hello(&name);
goodbye(&name);
}
The `main.rs` listing shows `mod input;` and `mod output;` declaring file-based modules while `use` brings selected functions into scope. section 5.1.2
Moving a function into a module changes how it is named and accessed. `main` can import `get_name` with `use input::get_name;`, but that import still fails if `get_name` is private. Mark a function `pub` when it must be used from another module. The same visibility rule applies to modules; `pub(crate)` makes an item public within its crate while keeping it private to other crates. section 5.1 section 5.4
Fix an import from a sibling module
Suppose `output.rs` needs the `DayKind` enum declared in `day_kind.rs`. `use day_kind::DayKind;` produces an unresolved-import error there. `use crate::day_kind::DayKind;` starts at the current crate’s root and resolves the path. section 5.1.2 section 5.2.1
Paths locate items in nested modules. A relative path is evaluated from the current module; `super` reaches its parent. An absolute path begins at a crate root, and `crate` names the current crate’s root. `use` can shorten a path where it is needed, while `pub use` can alias an item. Keep a module’s internal helpers private when callers do not need them. section 5.2.1 section 5.4
A `tests` module is another practical grouping: by convention, it sits close to the code it tests and uses `#[cfg(test)]` so it compiles only for tests. section 7.3
