this post was submitted on 07 Sep 2023
33 points (100.0% liked)
Rust
5960 readers
2 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Good work.
"Just don't write bugs" ( or "Just don't write semver violations" in this case) is now rightfully recognized as a joke proposition by many (although derivative ability/experience arguments are sometimes still used, UNIRONICALLY). But it's the "better education" (or its sister magic pill "better docs") that still has many believers. So it is still valuable to explicitly make the argument for reliable automated tooling as the only real logical solution. But I digress.
Violations in
#[doc(hidden)]
items should definitely trigger errors by default IMHO. To give what was a kludge in the first place more powers is not something I would call wise. Not to mention, module source code is just one click away from html docs, and it's also one click/key-combination away from a crate user's editor/IDE with LSP (rust-analyzer
).So
I would argue it's always the case, unless the user of the tool explicitly decides it's not.
What do you think
#[doc(hidden)]
is for, other than declaring something "private" that the language unfortunately doesn't let you declare as truly private right now?I've mostly seen it used as a way to expose tools to macro APIs. For example, these internal parts of the
quote!
macro, or these internal parts of thevec!
macro. Changing these things shouldn't be considered a semver violation, because they're not really part of the API, even though thequote!
macro can't enforce it.The only other cases I can think of where I've seen
#[doc(hidden)]
used are even bigger kludges, and the hidden items definitely aren't part of the platonic API, like pre-#[non_exhaustive]
crates that wanted to reserve the right to add new variants to their enums.Probably a spicy take, but I think any API being used by a macro should be made public. A macro shouldn't be the only way to do something; it should just be a way to remove the boilerplate required to do it.