From the perspective of a user I have agreed to this from the start. But from the developer perspective its actually important to know exactly where the types you are importing come from.
Thats why I think it would be nice to have some way of disallowing pub use within the crate itself and only allow pub use exports in release builds to expose the api to users.
what do you mean "from a developer perspective"? who is using rust other than developers?
changing the exported namespace based on the build profile is a very bad idea. remember that a crate built in debug mode will also build its dependencies in debug mode.
developer of the crate
that just has to change. There should be a build flag that indicates whether the crate is built for debugging of the crate or if it is built as a dependency. Obviously dependencies need to be built with their public api enabled.
testing should also be done with the public api enabled! if you mess up the declaration of the public api, the crate's tests should fail.
i think i understand your usecase, and i think a better way of expressing it would be a lint that forbids code from referencing a use declaration in the current crate but outside the current module. note that doing this does not require pub use at all, as seen in this playground example.
I live by a relaxed version of this rule, that I think gives all the good properties and avoid all the pitfalls mentioned in this thread.
Do not pub use any item from a pub mod.
So I do ither:
mod some_impl;
pub use some_impl:SomeType;
or
pub mod some_impl; // contains SomeType
but never:
pub mod some_impl;
pub use some_impl::SomeType
That way, the structure of the code matches the structure of the api, but I don't get source files that are just too long.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.