Skip to content

Rename mod.rs files to self.rs #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Rename mod.rs files to self.rs #128

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jun 18, 2014


# Motivation

The name _self.rs_ feels more logical for this purpose given how `self` in module-scope refers to the enclosing module. Also, `Self` is used to refer to the enclosing trait, so there's a strong precedent of using "self" to refer to the enclosing "thing". For a _self.rs_ file, the enclosing "thing" is the folder it lies in, and that folder's name is the name of the module for which the _self.rs_ file is the implementation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self is used to refer to the type implementing the enclosing trait, not the trait itself.

@ghost ghost mentioned this pull request Jun 18, 2014
@nmsmith
Copy link

nmsmith commented Jun 23, 2014

I think this is a worthwhile change for consistency, and the changeover wouldn't be much trouble.

@steveklabnik
Copy link
Member

I strongly prefer name_of_the_module.rs.

@bvssvni
Copy link

bvssvni commented Jun 23, 2014

I like to the keep the name of the module separate from the directory structure. This means you can copy & paste it to another project without needing to change the name in the source.

mod.rs has a connection to the convention of lib.rs and main.rs/bin.rs. The difference is that mod.rs is enforced by the compiler.

mod.rs is good enough for me, but I would not mind changing to self.rs either. To me it looks like choosing between two different conventions that both makes sense to some extent.

@mrhandle
Copy link

i am a newbie so take my view with a grain of salt

doesn't self refer to too many things already? this is bound to be confusing for newbies.

@ghost
Copy link
Author

ghost commented Jun 23, 2014

We could have a nice correspondence between import-trees and files/folders given the changes discussed here and particularly demonstrated by this comment

@alexchandel
Copy link

For those unaware, mod.rs is good because mod is a keyword. There could never be a module or submodule called mod mod or ::mod, or a normal file called mod.rs, so this blindspot in the configuration space of names is repurposed for the language. And after all, the mod.rs file contains the mod block for the directory, so it makes sense to call it mod.rs.

You could say the same for mod self. I see the appeal of self.rs due to its similarity to the self implementation parameter and the self module reference. But these meanings are unrelated. One refers to both the implicit self parameter and the type of said parameter, while the other refers to the current module namespace. But it feels a little abusive to me, to create a third meaning for self. I'm not sure there's enough overlap with any of the current meanings. Sure, self:: inside directory/self.rs still refers to the mod directory, but self:: inside some_other.rs refers to mod some_other, not the mod directory. And the complementary super.rs is still meaningless. But someone who knows more about the design of Rust's module system like @alexcrichton might have a clearer view of this.

I think name_of_the_directory_module.rs isn't very desirable, since this makes the foo::foo submodule impossible, or at least a convoluted case. I like keeping the "special" rust file independent of the directory naming. However, the fact that generally the filename is the name_of_the_module.rs is a reason self.rs works.

Edited for clarity.

@liigo
Copy link
Contributor

liigo commented Jun 26, 2014

I prefer mod.rs.

@alexcrichton
Copy link
Member

Thanks for taking the time to write an RFC! We talked about this at today's triage meeting, and we've decided to not change the conventions which we have in place today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants