Skip to content
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

Prefer super or crate for internal module references #167

Closed
tisonkun opened this issue Nov 23, 2021 · 3 comments
Closed

Prefer super or crate for internal module references #167

tisonkun opened this issue Nov 23, 2021 · 3 comments

Comments

@tisonkun
Copy link

We can refer to modules in the same crate in different ways. For example, given a crate like this:

src/
  lib.rs
  a.rs
  b.rs

a can import trait B in b as crate::b::B or super::b::B. And if B is pub use in lib.rs, a can also refer B as crate::B. All these work, but it is troublesome to think about which way to go every time. So I think it will be better if we have a guideline about this.

My opinion is that we should prefer referring things relatively using super::b::B because:

  • It doesn't assume if B is public or not
  • When refactoring file structure, for example, if we want to move a.rs and b.rs to a sub-directory, the code still works

Originally posted by @huachaohuang in rust-lang/api-guidelines#255

@huachaohuang
Copy link

Thanks for moving it here. I am not that obsessed about this now. I think for internal usages, it is fine to choose any way that works.

@tisonkun
Copy link
Author

@huachaohuang fine. If B is not public, the compiler will complain. For refactor purposes, the compiler will also help in spotting, and refactor tools will help.

I'll keep this issue open for a while to further comments if any.

@calebcartwright
Copy link
Member

Thanks for reaching out but I'm going to close this as it's not really the type of thing we can codify in this guideline which is really geared to how the code the developer wrote should be styled/formatted (as opposed to analyzing the entirety of the crate to provide guidance on what the developer should have written.

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

No branches or pull requests

3 participants