Skip to content

rustdoc: split out trait implementer's notes from method docs #139855

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
llogiq opened this issue Apr 15, 2025 · 4 comments
Open

rustdoc: split out trait implementer's notes from method docs #139855

llogiq opened this issue Apr 15, 2025 · 4 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. needs-rfc This change is large or controversial enough that it should have an RFC accepted before doing it. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@llogiq
Copy link
Contributor

llogiq commented Apr 15, 2025

On mastodon, Simon Tatham alerted us to the problem that rustdoc will show the method docs from a trait on an implementation of that trait, which may contain parts geared towards implementers, not users of the trait.

There is currently no way to distinguish those in a way that would let rustdoc show the implementer's notes on the trait docs but not on trait implementations.

Since doc comments get lowered to attributes, the lowest common. denominator would be an attribute like #[traitdoc = "..."] that works like #[doc = "..."] but is included by rustdoc only on the doc pages for the trait itself, not on the implementation docs.

In addition, there could be a doc comment variant (perhaps ///^ and //!^ respectively) that lowers to #[traitdoc] attributes. This might need an edition though. Alternatively, rust could pick up on an ## Implementer's notes section header instead and emit #[traitdoc] instead of #[doc] attributes for that whole section.

Example

As an example, the PartialEq::ne method could be documented as follows (other methods and attributes have been removed for brevity):

pub trait PartialEq<Rhs: ?Sized = Self> {
    /// Tests for `self != other`.
    #[traitdoc="The default implementation is almost always sufficient,"]
    #[traitdoc="and should not be overridden without very good reason."]
    fn ne(&self, other: &Rhs) -> bool {
        !self.eq(other)
    }
}

Open questions:

  • Attribute naming: Some alternatives are impldoc, trait_doc, trait-doc, impl-doc.
  • Section header or doc comment variant? If the latter, which sigil to append?

cc @GuillaumeGomez

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 15, 2025
@fmease fmease added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. needs-rfc This change is large or controversial enough that it should have an RFC accepted before doing it. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Apr 15, 2025
@GuillaumeGomez
Copy link
Member

Here is the solution I have in mind:

/// Docs visible by everyone.
#[doc(visible_on_trait_only = true)]
/// This is how to implement the trait.
/// blablabla
#[doc(visible_on_trait_only = false)]
/// eventually more docs

We could add a new doc attribute which would make the documentation between these attributes only visible on the trait page and not on the implementors. The #[doc(visible_on_trait_only = false)] one would be optional if there is no doc afterward.

What do you think?

@GuillaumeGomez
Copy link
Member

Also cc @sgtatham.

@llogiq
Copy link
Contributor Author

llogiq commented Apr 16, 2025

@GuillaumeGomez looks good as a starting point. With that said, such a toggle attribute might complicate parsing and conversion in case we decide to go ahead with a comment prefix shortcut later. Remember, this would also be for library authors to document their traits.

@GuillaumeGomez
Copy link
Member

I don't think there will ever be more syntax sugar ever added for doc comments (if that's what you meant).

And do you mean parsing/conversion for humans or for rustdoc?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. needs-rfc This change is large or controversial enough that it should have an RFC accepted before doing it. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants