Remove uses of doc(hidden) to create private APIs #1564
Description
Activity
- addedtracking-issueIssue to track multiple changes or collect information.Issue to track multiple changes or collect information.docsIssues relating primarily to documentation or API visibility.Issues relating primarily to documentation or API visibility.
on Jan 4, 2026 just for clarification instances like this: https://github.com/rust-ndarray/ndarray/blob/master/src/private.rs should still be treated as acceptable use for doc(hidden) right?
Yes! Not that I love the existence of our private markers, but it is a good use case
Reacted by stoutes@akern40
wanted to ask this as well so for some of the functions its a fairly simple task but a lot of these are within trait methods, which I think would require a sealed trait / split trait refactor (it might get a little beefy).would you want to just take care of some of the simple ones first in one MR and do the trait methods in a separate MR? Just don't want to overload y'all with a big MR. Unless it's not a big deal and then I'll just include everything together.
btw just for the record I'll take this one.
My thought is that these are each individual cases. The question is basically a) why is this hidden? b) should it remain hidden? and c) if so, can we make it hidden without just hiding its docs.
For functions this should be pretty easy. It's trickier for trait methods.
Reacted by stoutes
The library liberally uses
#[doc(hidden)]to "hide" APIs that it wants to be internal. This poses a slight challenge to maintenance, since changing those is technically a public breaking change. Although this may be necessary or desired in some cases, I believe that most instance should be altered to no longer be publicly visible.Once finished, remove this line from the crate documentation.