Filesystem Hierarchy

Omitting the module content will tell Rust to look for it in another file:

1. ```
   mod garden;
   ```

This tells Rust that the garden module content is found at src/garden.rs. Similarly, a garden::vegetables module can be found at src/garden/vegetables.rs.

The crate root is in:

• src/lib.rs (for a library crate)
• src/main.rs (for a binary crate)

Modules defined in files can be documented, too, using “inner doc comments”. These document the item that contains them — in this case, a module.

1. ```
   //! This module implements the garden, including a highly performant germination
   ```
2. ```
   //! implementation.
   ```

4. ```
   // Re-export types from this module.
   ```
5. ```
   pub use garden::Garden;
   ```
6. ```
   pub use seeds::SeedPacket;
   ```

8. ```
   /// Sow the given seed packets.
   ```
9. ```
   pub fn sow(seeds: Vec<SeedPacket>) {
   ```
10. ```
        todo!()
    ```
11. ```
    }
    ```

13. ```
    /// Harvest the produce in the garden that is ready.
    ```
14. ```
    pub fn harvest(garden: &mut Garden) {
    ```
15. ```
        todo!()
    ```
16. ```
    }
    ```

This slide should take about 5 minutes.

• Before Rust 2018, modules needed to be located at module/mod.rs instead of module.rs, and this is still a working alternative for editions after 2018.
• The main reason to introduce filename.rs as alternative to filename/mod.rs was because many files named mod.rs can be hard to distinguish in IDEs.
• Deeper nesting can use folders, even if the main module is a file:

1. src/ 2. ├── main.rs 3. ├── top_module.rs 4. └── top_module/ 5. └── sub_module.rs - The place rust will look for modules can be changed with a compiler directive:

1. #[path = "some/path.rs"] 2. mod some_module;

This is useful, for example, if you would like to place tests for a module in a file named some_module_test.rs, similar to the convention in Go.