I've read uncountable questions on splitting rust modules on different files, and surprising none seem to address what I see as a most natural problem.
So the question is not how should I have split a module, but how to do it once the module is already written. And the main problem, that no one seems to tackle is how to get around visibility. Pleas don't mark as a duplicate if the answer don't solve this problem.
When I have a module doing a few 100's lines with plenty of structs and functions, pretty much everyone calling each other and accessing members of struct and then I decide to split the module in two files, is pretty easy to put the functions and structs I want on two different files, but everything of one file is private to the other now. The only solution I have found is redeclaring every single object of each file as "pub", which is a very unsatisfactory solution because: i) is manual ii) teaches me to declare everything by default as pub to avoid this potential problem later.
using pub mod
does not seem to change anything, because functions that were not public in the module remain not public.
What I would like is a way to make everything on a file (or module) public by default, a little bit like c++ public:
but a way to automatically refactor a file would also be nice.
Asked
Active
Viewed 156 times
1

user2759511
- 640
- 7
- 16
-
1You may annotate the functions/types with `pub(super)` (or `pub(crate)` for even wider visibility) so that they are only exposed up to the parent module (or to the whole crate, respectively) (but not to outside the crate). However, AFAIK there is no other method to apply visibility to a group of types/functions than to annotate each of them. – Ruifeng Xie Jul 18 '21 at 17:22
-
1Sorry but this sounds like a rant that you just don't like the *"if you want your structs and fields to be visible outside the module, they must be pub"* answer. You could potentially resort to macros like [this answer](https://stackoverflow.com/a/53869723) but that's not idiomatic. What *IS* idiomatic would be to take your time and asses your encapsulation and determine if everything *needs* to be publicly visible; visibility is part of the contract the compiler will enforce on the rest of the code. If you deem that *everything* should be `pub` then so be it, you should make them so. – kmdreko Jul 18 '21 at 17:29
-
I disagree, it is a real questions, and I do hope that I can get an answer. I proposed two hypothetically possible ways of solving the problem I I have a hope that at least one of them actually exist. Of course, my frustration may have transpired, in which case I apologize, but I feel that this is very much a legitimate question to a legitimate problem – user2759511 Jul 18 '21 at 18:36
-
about not liking the other answer, that's a unfair characterization of my opinion, it's not a question of liking, I gave two (in my opinion) good, objective reasons why they are a bad technical solution. I could have gone in more detail, but I kept short to indicate which kind of answer would be useful to me – user2759511 Jul 18 '21 at 18:40
-
I think the idea of Rust is to force us to write safe code, including that anyone reading the source immediatly knows what it means. This includes to mark each and every single object and function as public that needs to be public. This is the same issue as using `mut`. -- If you want a language that has this bit of non-safety, use another language. -- While discussing language design decisions, I think there is rarely an objective reason, TBH. (No offend, just something to think about.) – the busybee Jul 18 '21 at 19:38
-
1Anyway, if your architecture wants two modules that closely coupled, I'm afraid that architecture might be defect. Please show us a [example]. – the busybee Jul 18 '21 at 19:39
-
1If you have many files with interdependencies on the fields of eachothers' structs, that's not good encapsulation. There's nothing wrong with having more than one struct with impl's that are by necessity tightly coupled in the same file, but usually projects can be partitioned in a way where files don't become too large and are well encapsulated. – Todd Jul 19 '21 at 05:40