But we don't get any errors or warning when compiling. The zip crate builds without error
But if I change pub ZipFileData to pub(crate) ZipFileData the build produces warning
warning: type `ZipFileData` is more private than the item `HasZipMetadata::get_metadata`
--> src/read.rs:731:5
|
731 | fn get_metadata(&self) -> &ZipFileData;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ method `HasZipMetadata::get_metadata` is reachable at visibility `pub`
|
note: but type `ZipFileData` is only usable at visibility `pub(crate)`
2. But it was already the case no? In both case I cannot use ZipFileData right ?
The unnameable_types lint, which is allowed by default, would catch this. I feel like an unnameable type is more commonly a mistake than not, but I guess the language developers don't want to overwhelm people with lints by default.
Personally, I enable almost every lint (out of over 800 clippy lints and however many rustc lints, I have maybe 35-40 disabled).
there's differnence between a type that is private and a type that is unnamable (e.g. inside a private module,).
a public type can be unnamable. it is public so you can use it from an downstream crate. but because you can't name it, you will not use it when explicit type annotation is required; nevertheless, you can happily use it in context where it can be inferred or elided.
currently, rustdoc doesn't generate for such unnamable types within private modules, unless you also enable documentation for the private modules.
Okay that's why I have this on the docs.rs website.
Is there a reason for rustdoc to not generate docs for unnamable types? Since we can still use them (for me, it would be logic to have the docs available)
I don't know the answer for sure, but I guess rustdoc doesn't do full reachability analysis, it probably culls the items in a simple top-down fashion. when it saw a private module, it simply skips the entire module, that's my guess.