Multiple visibility paths

Currently, it's not possible to denote where a certain code is visible when your target path is not just one.

It'd be great if we could something like:

pub(in crate::{adapters::repositories, services::views}) async fn your_function(){
/// your code here

}

This seems like a high-overhead way to maintain very fine-grained boundaries inside one crate. What is the advantage of this over pub(crate)?

2 Likes

pub(in path) basically shouldn't be used for paths that aren't a parent to the definition path, and last I heard it doesn't even work as you might expect if you do specify a sibling path.

Narrow visibility that jumps across module boundaries like this almost always is an indicator of poorly structured code. Either it's a reasonable helper to be available and it can be pub(crate), even if most modules won't be interested, or it's tightly coupled to local details and should be pub(self) (or sometimes pub(super) when splitting large modules into submodules for practicality) and kept close to the code that uses it.

Module API is less critical than crate API, but it has mostly the same design considerations. It doesn't make much sense to say other code can see this, but only if it's in this specific other crate/module — either it's okay to use outside of home or it isn't.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.