#Modules themselves don't know they are modules

25 messages · Page 1 of 1 (latest)

ivory socket
#

I'm discovering rust modules for the first time and it is not intuitive to me because I'm expecting some sort of declaration at the top of a file to say what module it is.

In Rust however, it seems that the only way to define a "module" is to include a file as a module from another file (parent file) following the naming convention of <module>.rs | /<module>/mod.rs but the module file itself doesn't have any decorators or attributes to tell the reader, "hey I'm a module".
In fact, if I wrap the module itself in a mod <module> { ... } then my namespace will contain two instances of the module, eg crate::<module>::<module>::...

So whilst I understand the mechanics around this portion of the module system, I'm finding it different to what I'm used to where module declarations are part of the module file itself.

Is my understanding correct?
Is there somewhere that talks about this kind of design?

final saddle
#

that sounds fairly accurate

#

one way i like to look at it is that the code declares the way it "expands". if lib.rs has mod abc;, only then rust is allowed to look at abc.rs or abc/mod.rs.

#

mod stuff {} is only for inline modules: that is, it's only intended to be used as a subsection of a file, not the entire file

jade zealot
#

module file itself doesn't have any decorators or attributes to tell the reader, "hey I'm a module"
Every file is a module, so the fact that it's a file is enough to know it's a module. Modules are the only thing that rust code can exist in.

#

It doesn't tell you what the parent is for that module, which is a little inconvenient but there's only two possible files for any given module that can be its parent so it's not that bad (besides using custom path attributes, but those are rare)

ivory socket
#

yeah, I should add that coming from Elm, I'm totally expecting something like

// src/abc/xyz.rs
module abc.xyz exposing (..)

in the file itself.

I think it actually ends up being exactly the same... but I'm having to explicitly build up that hierarchy of connections from one module to the next...

image.png
#

I'm ok with it, haven't used it enough yet, but it's good to figure this out cause I was having trouble trying to reference a module that wasn't being added in a previous one so it wasn't available in the namespace.

short coral
#

the rust system of implicit file-modules is superior imo

jade zealot
#

Yeah rust-analyzer will help you with declaring modules as well.

iron barn
#

note that you do not have to look at the parent to get most of the key information about a module

#

for example, the documentation of a module is usually written in the file, not outside, even though it could be

#

the things it exports are specified inside the file

#

the one big thing that is not inside the file is whether the module is public, but since Rust visibility is nesting-sensitive you would have to look at all of its parents even if the pub was syntactically inside

ivory socket
#

another one is attributes, and this is quite nice. I've got a bindgen module that breaks linting and i've just realised i can attribute the module from the caller

iron barn
#

(and things can be reexported anyway from pub use)

ivory socket
iron barn
ivory socket
iron barn
#

yes

#

/// x is syntax sugar for #[doc = " x"]
//! x is syntax sugar for #![doc = " x"]

#

(this does not mean that the documentation is in any way stored in the compiled library. It's just part of the syntax tree beyond just being comments

#

which is useful because it can be manipulated by macros

jade zealot
ivory socket
#

yeah icic.. and that comes up in cargo doc --open which i just discovered yesterday