You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove uses of doc(hidden) to create private APIs #1564
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.
@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.
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.
Activity
stoutes commentedon Jan 20, 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?
akern40 commentedon Jan 20, 2026
Yes! Not that I love the existence of our private markers, but it is a good use case
stoutes commentedon Jan 20, 2026
@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.
akern40 commentedon Jan 21, 2026
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.